Printer controller configured to compensate for dead printhead nozzles

ABSTRACT

A printer controller for compensating for an inoperative nozzle in a printhead is provided. The printhead includes a plurality of nozzles associated with each pixel to be printed, the printer controller being operative to control one or more operative nozzles associated with the same pixel as the inoperative nozzle to increase the amount of printing substance expelled by the one or more operative nozzles.

CROSS REFERENCE TO RELATED APPLICATION

This application is a continuation of U.S. Ser. No. 11/442,131 filed May30, 2006, which is a continuation of U.S. Ser. No. 10/727,233 filed Dec.2, 2003, now issued U.S. Pat. No. 7,165,824, the entire contents ofwhich are herein incorporated by reference.

FIELD OF INVENTION

The present invention relates to the compensating a channel in aprinthead where one or more ink nozzles in the printhead are dead.

The invention has primarily been developed for use with a printheadcomprising one or more printhead modules constructed usingmicroelectromechanical systems (MEMS) techniques, and will be describedwith reference to this application. However, it will be appreciated thatthe invention can be applied to other types of printing technologies inwhich analogous problems are faced.

BACKGROUND OF INVENTION

Manufacturing a printhead that has relatively high resolution andprint-speed raises a number of problems. Difficulties in manufacturingpagewidth printheads of any substantial size arise due to the relativelysmall dimensions of standard silicon wafers that are used in printhead(or printhead module) manufacture. For example, if it is desired to makean 8 inch wide pagewidth printhead, only one such printhead can be laidout on a standard 8-inch wafer, since such wafers are circular in plan.Manufacturing a pagewidth printhead from two or more smaller modules canreduce this limitation to some extent, but raises other problems relatedto providing a joint between adjacent printhead modules that is preciseenough to avoid visible artefacts (which would typically take the formof noticeable lines) when the printhead is used. The problem isexacerbated in relatively high-resolution applications because of thetight tolerances dictated by the small spacing between nozzles.

The quality of a joint region between adjacent printhead modules relieson factors including a precision with which the abutting ends of eachmodule can be manufactured, the accuracy with which they can be alignedwhen assembled into a single printhead, and other more practical factorssuch as management of ink channels behind the nozzles. It will beappreciated that the difficulties include relative vertical displacementof the printhead modules with respect to each other.

Whilst some of these issues may be dealt with by careful design andmanufacture, the level of precision required renders it relativelyexpensive to manufacture printheads within the required tolerances. Itwould be desirable to provide a solution to one or more of the problemsassociated with precision manufacture and assembly of multiple printheadmodules to form a printhead, and especially a pagewidth printhead.

In some cases, it is desirable to produce a number of differentprinthead module types or lengths on a substrate to maximise usage ofthe substrate's surface area. However, different sizes and types ofmodules will have different numbers and layouts of print nozzles,potentially including different horizontal and vertical offsets. Wheretwo or more modules are to be joined to form a single printhead, thereis also the problem of dealing with different seam shapes betweenabutting ends of joined modules, which again may incorporate vertical orhorizontal offsets between the modules. Printhead controllers areusually dedicated application specific integrated circuits (ASICs)designed for specific use with a single type of printhead module, thatis used by itself rather than with other modules. It would be desirableto provide a way in which different lengths and types of printheadmodules could be accounted for using a single printer controller.

Printer controllers face other difficulties when two or more printheadmodules are involved, especially if it is desired to send dot data toeach of the printheads directly (rather than via a single printheadconnected to the controller). One concern is that data delivered todifferent length controllers at the same rate will cause the shorter ofthe modules to be ready for printing before any longer modules. Wherethere is little difference involved, the issue may not be of importance,but for large length differences, the result is that the bandwidth of ashared memory from which the dot data is supplied to the modules iseffectively left idle once one of the modules is full and the remainingmodule or modules is still being filled. It would be desirable toprovide a way of improving memory bandwidth usage in a system comprisinga plurality of printhead modules of uneven length.

In any printing system that includes multiple nozzles on a printhead orprinthead module, there is the possibility of one or more of the nozzlesfailing in the field, or being inoperative due to manufacturing defect.Given the relatively large size of a typical printhead module, it wouldbe desirable to provide some form of compensation for one or more “dead”nozzles. Where the printhead also outputs fixative on a per-nozzlebasis, it is also desirable that the fixative is provided in such a waythat dead nozzles are compensated for.

A printer controller can take the form of an integrated circuit,comprising a processor and one or more peripheral hardware units forimplementing specific data manipulation functions. A number of theseunits and the processor may need access to a common resource such asmemory.

One way of arbitrating between multiple access requests for a commonresource is timeslot arbitration, in which access to the resource isguaranteed to a particular requester during a predetermined timeslot.

One difficulty with this arrangement lies in the fact that not allaccess requests make the same demands on the resource in terms of timingand latency. For example, a memory read requires that data be fetchedfrom memory, which may take a number of cycles, whereas a memory writecan commence immediately. Timeslot arbitration does not take intoaccount these differences, which may result in accesses being performedin a less efficient manner than might otherwise be the case. It would bedesirable to provide a timeslot arbitration scheme that improved thisefficiency as compared with prior art timeslot arbitration schemes.

Also of concern when allocating resources in a timeslot arbitrationscheme is the fact that the priority of an access request may not be thesame for all units. For example, it would be desirable to provide atimeslot arbitration scheme in which one requester (typically thememory) is granted special priority such that its requests are dealtwith earlier than would be the case in the absence of such priority.

In systems that use a memory and cache, a cache miss (in which anattempt to load data or an instruction from a cache fails) results in amemory access followed by a cache update. It is often desirable whenupdating the cache in this way to update data other than that which wasactually missed. A typical example would be a cache miss for a byteresulting in an entire word or line of the cache associated with thatbyte being updated. However, this can have the effect of tying upbandwidth between the memory (or a memory manager) and the processorwhere the bandwidth is such that several cycles are required to transferthe entire word or line to the cache. It would be desirable to provide amechanism for updating a cache that improved cache update speed and/orefficiency.

Most integrated circuits an externally provided signal as (or togenerate) a clock, often provided from a dedicated clock generationcircuit. This is often due to the difficulties of providing an onboardclock that can operate at a speed that is predictable. Manufacturingtolerances of such on-board clock generation circuitry can result inclock rates that vary by a factor of two, and operating temperatures canincrease this margin by an additional factor of two. In some cases, theparticular rate at which the clock operates is not of particularconcern. However, where the integrated circuit will be writing to aninternal circuit that is sensitive to the time over which a signal isprovided, it may be undesirable to have the signal be applied for toolong or short a time. For example, flash memory is sensitive to beingwritten too for too long a period. It would be desirable to provide amechanism for adjusting a rate of an on-chip system clock to take intoaccount the impact of manufacturing variations on clockspeed.

SUMMARY OF THE INVENTION

In a broad form, the present invention provides a printer controllerable to compensate for an inoperative nozzle in a printhead, theprinthead including a plurality of sets of nozzles for printing acorresponding plurality of channels of dot data, the printhead operatedby the printer controller which is able to determine one or moreoperative nozzles capable of printing a dot on a print media near aposition at which the inoperative nozzle would have printed a dot had itbeen operative.

In a particular form, the printhead is segmented as a bi-lithicprinthead. In other particular forms: the printer controller compensatesfor an inoperative nozzle in the printhead by using color redundancy;the channels of dot data are mapped from the inoperative nozzle to thedetermined one or more operative nozzles; the channels of dot data aremapped from the inoperative nozzle to a color plane of the determinedone or more operative nozzles; the mapping of the channels of dot datato the color plane is programmable; there are six channels of dot dataand the dot data is bi-level dot data; the channels of dot data areloaded from DRAM and are then passed to the printer controller via aFIFO buffer; and/or information indicating inoperative nozzles is storedin a table.

In another non-limiting embodiment, the table is updated by performingan inoperative nozzle test including the steps of: running a printheadnozzle test sequence; converting inoperative nozzle information into aninoperative nozzle table; and, writing the inoperative nozzle table to amemory of the printer controller.

In another non-limiting embodiment, the printer controller isadditionally able to: (a) form a compressed bi-level layer for a givenprint line intended for the bi-lithic printhead; (b) expand thecompressed bi-level layer; (c) composite the bi-level layer to producebi-level dots; (d) determine which combination of one or more availableoperative nozzles near the inoperative nozzle reduces perceived error inan image that the dot data forms part of, the determination beingperformed on the basis of a color model; (e) map the dot data intendedfor the inoperative nozzle to the combination of one or more operativenozzles; and, (f) pass resultant bi-level channel dot data to thebi-lithic printhead.

According to various other forms, the one or more operative nozzlescapable of printing a dot on the print media are immediately adjacentthe position at which the inoperative nozzle would have printed a dothad it been operative; during successive firings of the printhead, thedot data is remapped alternately to operative nozzles capable ofprinting a dot on the print media either side of that which would havebeen printed by the inoperative nozzle; during successive firings of theprinthead, the dot data is remapped randomly, pseudo-randomly, orarbitrarily to operative nozzles capable of printing a dot on the printmedia either side of that which would have been printed by theinoperative nozzle; the inoperative nozzle is associated with a blackprint channel, and wherein the dot data intended for the inoperativenozzle is mapped into a plurality of operative nozzles in other colorchannels to produce a process black output at or adjacent a location onprint media where the inoperative nozzle would have deposited a dot of ablack printing substance in accordance with the dot data.

BRIEF DESCRIPTION OF THE DRAWINGS

Preferred and other embodiments of the invention will now be described,by way of example only, with reference to the accompanying drawings, inwhich:

FIG. 1 shows document data flow in a printer;

FIG. 2 shows pages containing different numbers of bands;

FIG. 3 shows the contents of a page band;

FIG. 4 illustrates a page data path from host to SoPEC;

FIG. 5 shows a page structure;

FIG. 6 shows a SoPEC system top level partition;

FIG. 7 shows a SoPEC CPU memory map (not to scale);

FIG. 8 shows a SoPEC system top level partition;

FIG. 9 shows an outline of contone data flow with respect to CDU;

FIG. 10 shows a DRAM storage arrangement for a single line of JPEG 8×8blocks in 4 colors;

FIG. 11 shows a high level block diagram showing the HCU and itsexternal interfaces;

FIG. 12 shows a block diagram of the HCU;

FIG. 13 shows a block diagram of the control unit;

FIG. 14 shows a block diagram of determine advdot unit;

FIG. 15 shows a page structure;

FIG. 16 shows a block diagram of a margin unit;

FIG. 17 shows a block diagram of a dither matrix table interface;

FIG. 18 shows an example of reading lines of dither matrix from DRAM;

FIG. 19 shows a state machine to read dither matrix table;

FIG. 20 shows a contone dotgen unit;

FIG. 21 shows a block diagram of dot reorg unit;

FIG. 22 shows an HCU to DNC interface (also used in DNC to DWU, LLU toPHI);

FIG. 23 shows SFU to HCU interface (all feeders to HCU);

FIG. 24 shows representative logic of the SFU to HCU interface;

FIG. 25 shows a high-level block diagram of DNC;

FIG. 26 shows a dead nozzle table format;

FIG. 27 shows set of dots operated on for error diffusion;

FIG. 28 shows a block diagram of DNC;

FIG. 29 shows a sub-block diagram of ink replacement unit;

FIG. 30 shows a dead nozzle table state machine;

FIG. 31 shows logic for dead nozzle removal and ink replacement;

FIG. 32 shows a sub-block diagram of error diffusion unit;

FIG. 33 shows a maximum length 32-bit LFSR used for random bitgeneration;

FIG. 34 shows a high-level data flow diagram of DWU in context;

FIG. 35 shows a printhead nozzle layout for 36-nozzle bi-lithicprinthead;

FIG. 36 shows a printhead nozzle layout for a 36-nozzle bi-lithicprinthead;

FIG. 37 shows a dot line store logical representation;

FIG. 38 shows a conceptual view of printhead row alignment;

FIG. 39 shows a conceptual view of printhead rows (as seen by the LLUand PHI);

FIG. 40 shows a comparison of 1.5× v 2× buffering;

FIG. 41 shows an even dot order in DRAM (increasing sense, 13320 dotwide line);

FIG. 42 shows an even dot order in DRAM (decreasing sense, 13320 dotwide line);

FIG. 43 shows a dotline FIFO data structure in DRAM;

FIG. 44 shows a DWU partition;

FIG. 45 shows a buffer address generator sub-block;

FIG. 46 shows a DIU Interface sub-block;

FIG. 47 shows an interface controller state diagram;

FIG. 48 shows a high level data flow diagram of LLU in context;

FIG. 49 shows paper and printhead nozzles relationship (example withD₁=D₂=5);

FIG. 50 shows printhead structure and dot generate order;

FIG. 51 shows an order of dot data generation and transmission;

FIG. 52 shows a conceptual view of printhead rows;

FIG. 53 shows a dotline FIFO data structure in DRAM (LLU specification);

FIG. 54 shows an LLU partition;

FIG. 55 shows a dot generator RTL diagram;

FIG. 56 shows a DIU interface;

FIG. 57 shows an interface controller state diagram; and

FIG. 58 shows high-level data flow diagram of PHI in context.

DETAILED DESCRIPTION OF PREFERRED AND OTHER EMBODIMENTS

Imperative phrases such as “must”, “requires”, “necessary” and“important” (and similar language) should be read as being indicative ofbeing necessary only for the preferred embodiment actually beingdescribed. As such, unless the opposite is clear from the context,imperative wording should not be interpreted as such. Nothing in thedetailed description is to be understood as limiting the scope of theinvention, which is intended to be defined as widely as is defined inthe accompanying claims.

Indications of expected rates, frequencies, costs, and otherquantitative values are exemplary and estimated only, and are made ingood faith. Nothing in this specification should be read as implyingthat a particular commercial embodiment is or will be capable of aparticular performance level in any measurable area.

It will be appreciated that the principles, methods and hardwaredescribed throughout this document can be applied to other fields. Muchof the security-related disclosure, for example, can be applied to manyother fields that require secure communications between entities, andcertainly has application far beyond the field of printers.

The preferred of the present invention is implemented in a printer usingmicroelectromechanical systems (MEMS) printheads. The printer canreceive data from, for example, a personal computer such as an IBMcompatible PC or Apple computer. In other embodiments, the printer canreceive data directly from, for example, a digital still or videocamera. The particular choice of communication link is not important,and can be based, for example, on USB, Firewire, Bluetooth or any otherwireless or hardwired communications protocol.

Print System Overview

This document describes the SoPEC (Small office home office Print EngineController) ASIC (Application Specific Integrated Circuit) suitable foruse in, for example, SoHo printer products. The SoPEC ASIC is intendedto be a low cost solution for bi-lithic printhead control, replacing themultichip solutions in larger more professional systems with a singlechip. The increased cost competitiveness is achieved by integratingseveral systems such as a modified PEC1 printing pipeline, CPU controlsystem, peripherals and memory sub-system onto one SoC ASIC, reducingcomponent count and simplifying board design.

Bi-Lithic Printhead Notation

A bi-lithic based printhead is constructed from 2 printhead ICs ofvarying sizes. The notation M:N is used to express the size relationshipof each IC, where M specifies one printhead IC in inches and N specifiesthe remaining printhead IC in inches.

DEFINITIONS

The following terms are used throughout this specification: Bi-lithicprinthead: refers to printhead constructed from 2 printhead ICs; CPU:refers to CPU core, caching system and MMU; ISI-Bridge chip: a devicewith a high speed interface (such as USB2.0, Ethernet or IEEE1394) andone or more ISI interfaces. The ISI-Bridge would be the ISIMaster foreach of the ISI buses it interfaces to; ISIMaster: the ISIMaster is theonly device allowed to initiate communication on the Inter SopecInterface (ISI) bus. The ISIMaster interfaces with the host; ISISlave.Multi-SoPEC systems will contain one or more ISISlave SoPECs connectedto the ISI bus. ISISlaves can only respond to communication initiated bythe ISIMaster; LEON: refers to the LEON CPU core; LineSyncMaster: theLineSyncMaster device generates the line synchronisation pulse that allSoPECs in the system must synchronise their line outputs to;Multi-SoPEC: refers to SoPEC based print system with multiple SoPECdevices; Netpage: refers to page printed with tags (normally in infraredink); PEC1: refers to Print Engine Controller version 1, precursor toSoPEC used to control printheads constructed from multiple angledprinthead segments; Printhead IC: single MEMS IC used to constructbi-lithic printhead; PrintMaster: the PrintMaster device is responsiblefor coordinating all aspects of the print operation. There may only beone PrintMaster in a system; QA Chip: Quality Assurance Chip; StorageSoPEC: an ISISlave SoPEC used as a DRAM store and which does not print;and Tag: refers to pattern which encodes information about its positionand orientation which allow it to be optically located and its datacontents read.

Acronyms and Abbreviations

The following acronyms and abbreviations are used in this specification:CDU Contone Decoder Unit; CFU Contone FIFO Unit; CPU Central ProcessingUnit; CPR Clock, Power and Reset block; DIU DRAM Interface Unit; DNCDead Nozzle Compensator; DRAM Dynamic Random Access Memory; DWU DotlineWriter Unit; GPIO General Purpose Input Output; HCU Halftoner CompositorUnit; ICU Interrupt Controller Unit; ISI Inter SoPEC Interface; LDBLossless Bi-level Decoder; LLU Line Loader Unit; LSS Low Speed Serialinterface; MEMS Micro Electro Mechanical System; MMU Memory ManagementUnit; PCU SoPEC Controller Unit/PEP controller; PHI PrintHead Interface;PSS Power Save Storage Unit; RDU Real-time Debug Unit; ROM Read OnlyMemory/Boot ROM; SCB Serial Communication Block; SFU Spot FIFO Unit;SMG4 Silverbrook Modified Group 4; SoPEC Small office home office PrintEngine Controller; SRAM Static Random Access Memory; TE Tag Encoder; TFUTag FIFO Unit; TIM Timers Unit/General Timer; and USB Universal SerialBus.

Printing Considerations

A bi-lithic printhead produces 1600 dpi bi-level dots. On low-diffusionpaper, each ejected drop forms a 22.5 μm diameter dot. Dots are easilyproduced in isolation, allowing dispersed-dot dithering to be exploitedto its fullest. Since the bi-lithic printhead is the width of the pageand operates with a constant paper velocity, color planes are printed inperfect registration, allowing ideal dot-on-dot printing. Dot-on-dotprinting minimizes ‘muddying’ of midtones caused by inter-color bleed.

A page layout may contain a mixture of images, graphics and text.Continuous-tone (contone) images and graphics are reproduced using astochastic dispersed-dot dither. Unlike a clustered-dot (oramplitude-modulated) dither, a dispersed-dot (or frequency-modulated)dither reproduces high spatial frequencies (i.e. image detail) almost tothe limits of the dot resolution, while simultaneously reproducing lowerspatial frequencies to their full color depth, when spatially integratedby the eye. A stochastic dither matrix is carefully designed to be freeof objectionable low-frequency patterns when tiled across the image. Assuch its size typically exceeds the minimum size required to support aparticular number of intensity levels (e.g. 16×16×8 bits for 257intensity levels).

Human contrast sensitivity peaks at a spatial frequency of about 3cycles per degree of visual field and then falls off logarithmically,decreasing by a factor of 100 beyond about 40 cycles per degree andbecoming immeasurable beyond 60 cycles per degree. At a normal viewingdistance of 12 inches (about 300 mm), this translates roughly to 200-300cycles per inch (cpi) on the printed page, or 400-600 samples per inchaccording to Nyquist's theorem.

In practice, contone resolution above about 300 ppi is of limitedutility outside special applications such as medical imaging. Offsetprinting of magazines, for example, uses contone resolutions in therange 150 to 300 ppi. Higher resolutions contribute slightly to colorerror through the dither.

Black text and graphics are reproduced directly using bi-level blackdots, and are therefore not anti-aliased (i.e. low-pass filtered) beforebeing printed. Text should therefore be supersampled beyond theperceptual limits discussed above, to produce smoother edges whenspatially integrated by the eye. Text resolution up to about 1200 dpicontinues to contribute to perceived text sharpness (assuminglow-diffusion paper, of course).

A Netpage printer, for example, may use a contone resolution of 267 ppi(i.e. 1600 dp

6), and a black text and graphics resolution of 800 dpi. A high endoffice or departmental printer may use a contone resolution of 320 ppi(1600 dpi/5) and a black text and graphics resolution of 1600 dpi. Bothformats are capable of exceeding the quality of commercial (offset)printing and photographic reproduction.

Document Data Flow

Because of the page-width nature of the bi-lithic printhead, each pagemust be printed at a constant speed to avoid creating visible artifacts.This means that the printing speed can't be varied to match the inputdata rate. Document rasterization and document printing are thereforedecoupled to ensure the printhead has a constant supply of data. A pageis never printed until it is fully rasterized. This can be achieved bystoring a compressed version of each rasterized page image in memory.

This decoupling also allows the RIP(s) to run ahead of the printer whenrasterizing simple pages, buying time to rasterize more complex pages.Because contone color images are reproduced by stochastic dithering, butblack text and line graphics are reproduced directly using dots, thecompressed page image format contains a separate foreground bi-levelblack layer and background contone color layer. The black layer iscomposited over the contone layer after the contone layer is dithered(although the contone layer has an optional black component). A finallayer of Netpage tags (in infrared or black ink) is optionally added tothe page for printout. FIG. 1 shows the flow of a document from computersystem to printed page.

At 267 ppi for example, a A4 page (8.26 inches×11.7 inches) of contoneCMYK data has a size of 26.3 MB. At 320 ppi, an A4 page of contone datahas a size of 37.8 MB. Using lossy contone compression algorithms suchas JPEG, contone images compress with a ratio up to 10:1 withoutnoticeable loss of quality, giving compressed page sizes of 2.63 MB at267 ppi and 3.78 MB at 320 ppi.

At 800 dpi, a A4 page of bi-level data has a size of 7.4 MB. At 1600dpi, a Letter page of bi-level data has a size of 29.5 MB. Coherent datasuch as text compresses very well. Using lossless bi-level compressionalgorithms such as SMG4 fax, ten-point plain text compresses with aratio of about 50:1. Lossless bi-level compression across an averagepage is about 20:1 with 10:1 possible for pages which compress poorly.The requirement for SoPEC is to be able to print text at 10:1compression. Assuming 10:1 compression gives compressed page sizes of0.74 MB at 800 dpi, and 2.95 MB at 1600 dpi. Once dithered, a page ofCMYK contone image data consists of 116 MB of bi-level data. Usinglossless bi-level compression algorithms on this data is pointlessprecisely because the optimal dither is stochastic, since it introduceshard-to-compress disorder.

Netpage tag data is optionally supplied with the page image. Rather thanstoring a compressed bi-level data layer for the Netpage tags, the tagdata is stored in its raw form. Each tag is supplied up to 120 bits ofraw variable data (combined with up to 56 bits of raw fixed data) andcovers up to a 6 mm×6 mm area (at 1600 dpi). The absolute maximum numberof tags on a A4 page is 15,540 when the tag is only 2 mm×2 mm (each tagis 126 dots×126 dots, for a total coverage of 148 tags×105 tags). 15,540tags of 128 bits per tag gives a compressed tag page size of 0.24 MB.The multi-layer compressed page image format therefore exploits therelative strengths of lossy JPEG contone image compression, losslessbi-level text compression, and tag encoding. The format is compactenough to be storage-efficient, and simple enough to allowstraightforward real-time expansion during printing.

Since text and images normally don't overlap, the normal worst-case pageimage size is image only, while the normal best-case page image size istext only. The addition of worst case Netpage tags adds 0.24 MB to thepage image size. The worst-case page image size is text over image plustags. The average page size assumes a quarter of an average pagecontains images. Table 1 shows data sizes for compressed Letter page forthese different options.

TABLE 1 Data sizes for A4 page (8.26 inches × 11.7 inches) 267 ppicontone 320 ppi contone 800 dpi bi-level 1600 dpi bi-level Image only(contone), 2.63 MB 3.78 MB 10:1 compression Text only (bi-level), 0.74MB 2.95 MB 10:1 compression Netpage tags, 1600 dpi 0.24 MB 0.24 MB Worstcase (text + 3.61 MB 6.67 MB image + tags) Average (text + 25% 1.64 MB4.25 MB image + tags)

Document Data Flow

The Host PC rasterizes and compresses the incoming document on a page bypage basis. The page is restructured into bands with one or more bandsused to construct a page. The compressed data is then transferred to theSoPEC device via the USB link. A complete band is stored in SoPECembedded memory. Once the band transfer is complete the SoPEC devicereads the compressed data, expands the band, normalizes contone,bi-level and tag data to 1600 dpi and transfers the resultant calculateddots to the bi-lithic printhead. The document data flow is:

-   -   The RIP software rasterizes each page description and compress        the rasterized page image.    -   The infrared layer of the printed page optionally contains        encoded Netpage tags at a programmable density.    -   The compressed page image is transferred to the SoPEC device via        the USB normally on a band by band basis.    -   The print engine takes the compressed page image and starts the        page expansion.    -   The first stage page expansion consists of 3 operations        performed in parallel    -   expansion of the JPEG-compressed contone layer    -   expansion of the SMG4 fax compressed bi-level layer    -   encoding and rendering of the bi-level tag data.    -   The second stage dithers the contone layer using a programmable        dither matrix, producing up to four bi-level layers at        full-resolution.    -   The second stage then composites the bi-level tag data layer,        the bi-level SMG4 fax de-compressed layer and up to four        bi-level JPEG de-compressed layers into the full-resolution page        image.    -   A fixative layer is also generated as required.    -   The last stage formats and prints the bi-level data through the        bi-lithic printhead via the printhead interface.

The SoPEC device can print a full resolution page with 6 color planes.Each of the color planes can be generated from compressed data throughany channel (either JPEG compressed, bi-level SMG4 fax compressed, tagdata generated, or fixative channel created) with a maximum number of 6data channels from page RIP to bi-lithic printhead color planes.

The mapping of data channels to color planes is programmable, thisallows for multiple color planes in the printhead to map to the samedata channel to provide for redundancy in the printhead to assist deadnozzle compensation.

Also a data channel could be used to gate data from another datachannel. For example in stencil mode, data from the bilevel data channelat 1600 dpi can be used to filter the contone data channel at 320 dpi,giving the effect of 1600 dpi contone image.

Page Considerations Due to SoPEC

The SoPEC device typically stores a complete page of document data onchip. The amount of storage available for compressed pages is limited to2 Mbytes, imposing a fixed maximum on compressed page size. A comparisonof the compressed image sizes in Table 2 indicates that SoPEC would notbe capable of printing worst case pages unless they are split into bandsand printing commences before all the bands for the page have beendownloaded. The page sizes in the table are shown for comparisonpurposes and would be considered reasonable for a professional levelprinting system. The SoPEC device is aimed at the consumer level andwould not be required to print pages of that complexity. Target documenttypes for the SoPEC device are shown Table 2.

TABLE 2 Page content targets for SoPEC Page Content Size DescriptionCalculation (MByte) Best Case picture 8.26 × 11.7 × 267 × 267 × 3 1.97Image, 267 ppi with 3 @ 10:1 colors, A4 size Full page text, 800 8.26 ×11.7 × 800 × 800 @ 0.74 dpi A4 size 10:1 Mixed Graphics and Text 6 × 4 ×267 × 267 × 3 @ 5:1 1.55 Image of 6 inches × 4 800 × 800 × 73 @ 10:1inches @ 267 ppi and 3 colors Remaining area text ~73 inches², 800 dpiBest Case Photo, 3 Colors, 6.6 Mpixel @ 10:1 2.00 6.6 Megapixel Image

If a document with more complex pages is required, the page RIP softwarein the host PC can determine that there is insufficient memory storagein the SoPEC for that document. In such cases the RIP software can taketwo courses of action. It can increase the compression ratio until thecompressed page size will fit in the SoPEC device, at the expense ofdocument quality, or divide the page into bands and allow SoPEC to beginprinting a page band before all bands for that page are downloaded. OnceSoPEC starts printing a page it cannot stop, if SoPEC consumescompressed data faster than the bands can be downloaded a bufferunderrun error could occur causing the print to fail. A buffer underrunoccurs if a line synchronisation pulse is received before a line of datahas been transferred to the printhead.

Other options which can be considered if the page does not fitcompletely into the compressed page store are to slow the printing or touse multiple SoPECs to print parts of the page. A Storage SoPEC could beadded to the system to provide guaranteed bandwidth data delivery. Theprint system could also be constructed using an ISI-Bridge chip toprovide guaranteed data delivery.

Memjet Printer Architecture

The SoPEC device can be used in several printer configurations andarchitectures.

In the general sense every SoPEC based printer architecture willcontain:

-   -   One or more SoPEC devices.    -   One or more bi-lithic printheads.    -   Two or more LSS busses.    -   Two or more QA chips.    -   USB 1.1 connection to host or ISI connection to Bridge Chip.    -   ISI bus connection between SoPECs (when multiple SoPECs are        used).

System Components SoPEC Print Engine Controller

The SoPEC device contains several system on a chip (SoC) components, aswell as the print engine pipeline control application specific logic.

Print Engine Pipeline (PEP) Logic

The PEP reads compressed page store data from the embedded memory,optionally decompresses the data and formats it for sending to theprinthead. The print engine pipeline functionality includes expandingthe page image, dithering the contone layer, compositing the black layerover the contone layer, rendering of Netpage tags, compensation for deadnozzles in the printhead, and sending the resultant image to thebi-lithic printhead.

Embedded CPU

SoPEC contains an embedded CPU for general purpose system configurationand management. The CPU performs page and band header processing, motorcontrol and sensor monitoring (via the GPIO) and other system controlfunctions. The CPU can perform buffer management or report buffer statusto the host. The CPU can optionally run vendor application specific codefor general print control such as paper ready monitoring and LED statusupdate.

Embedded Memory Buffer

A 2.5 Mbyte embedded memory buffer is integrated onto the SoPEC device,of which approximately 2 Mbytes are available for compressed page storedata. A compressed page is divided into one or more bands, with a numberof bands stored in memory. As a band of the page is consumed by the PEPfor printing a new band can be downloaded. The new band may be for thecurrent page or the next page.

Using banding it is possible to begin printing a page before thecomplete compressed page is downloaded, but care must be taken to ensurethat data is always available for printing or a buffer underrun mayoccur. A Storage SoPEC acting as a memory buffer or an ISI-Bridge chipwith attached DRAM could be used to provide guaranteed data delivery.

Embedded USB 1.1 Device

The embedded USB 1.1 device accepts compressed page data and controlcommands from the host PC, and facilitates the data transfer to eitherembedded memory or to another SoPEC device in multi-SoPEC systems.

Bi-Lithic Printhead

The printhead is constructed by abutting 2 printhead ICs together. Theprinthead ICs can vary in size from 2 inches to 8 inches, so to producean A4 printhead several combinations are possible. For example twoprinthead ICs of 7 inches and 3 inches could be used to create a A4printhead (the notation is 7:3). Similarly 6 and 4 combination (6:4), or5:5 combination. For an A3 printhead it can be constructed from 8:6 oran 7:7 printhead IC combination. For photographic printing smallerprintheads can be constructed.

LSS Interface Bus

Each SoPEC device has 2 LSS system buses for communication with QAdevices for system authentication and ink usage accounting. The numberof QA devices per bus and their position in the system is unrestrictedwith the exception that PRINTER_QA and INK_QA devices should be onseparate LSS busses.

QA Devices

Each SoPEC system can have several QA devices. Normally each printingSoPEC will have an associated PRINTER_QA. Ink cartridges will contain anINK_QA chip. PRINTER_QA and INK_QA devices should be on separate LSSbusses. All QA chips in the system are physically identical with flashmemory contents defining PRINTER_QA from INK_QA chip.

ISI interface

The Inter-SoPEC Interface (ISI) provides a communication channel betweenSoPECs in a multi-SoPEC system. The ISIMaster can be SoPEC device or anISI-Bridge chip depending on the printer configuration. Both compresseddata and control commands are transferred via the interface.

ISI-Bridge Chip

A device, other than a SoPEC with a USB connection, which provides printdata to a number of slave SoPECs. A bridge chip will typically have ahigh bandwidth connection, such as USB2.0, Ethernet or IEEE1394, to ahost and may have an attached external DRAM for compressed page storage.A bridge chip would have one or more ISI interfaces. The use of multipleISI buses would allow the construction of independent print systemswithin the one printer. The ISI-Bridge would be the ISIMaster for eachof the ISI buses it interfaces to.

Page Format and Printflow

When rendering a page, the RIP produces a page header and a number ofbands (a non-blank page requires at least one band) for a page. The pageheader contains high level rendering parameters, and each band containscompressed page data. The size of the band will depend on the memoryavailable to the RIP, the speed of the RIP, and the amount of memoryremaining in SoPEC while printing the previous band(s). FIG. 3 shows thehigh level data structure of a number of pages with different numbers ofbands in the page.

Each compressed band contains a mandatory band header, an optionalbi-level plane, optional sets of interleaved contone planes, and anoptional tag data plane (for Netpage enabled applications). Since eachof these planes is optional, the band header specifies which planes areincluded with the band. FIG. 4 gives a high-level breakdown of thecontents of a page band. A single SoPEC has maximum renderingrestrictions as follows:

-   -   1 bi-level plane    -   1 contone interleaved plane set containing a maximum of 4        contone planes    -   1 tag data plane    -   a bi-lithic printhead with a maximum of 2 printhead ICs    -   The requirement for single-sided A4 single SoPEC printing is    -   average contone JPEG compression ratio of 10:1, with a local        minimum compression ratio of 5:1 for a single line of        interleaved JPEG blocks.    -   average bi-level compression ratio of 10:1, with a local minimum        compression ratio of 1:1 for a single line.

If the page contains rendering parameters that exceed thesespecifications, then the RIP or the Host PC must split the page into aformat that can be handled by a single SoPEC. In the general case, theSoPEC CPU must analyze the page and band headers and generate anappropriate set of register write commands to configure the units inSoPEC for that page. The various bands are passed to the destinationSoPEC(s) to locations in DRAM determined by the host.

The host keeps a memory map for the DRAM, and ensures that as a band ispassed to a SoPEC, it is stored in a suitable free area in DRAM. EachSoPEC is connected to the ISI bus or USB bus via its Serialcommunication Block (SCB). The SoPEC CPU configures the SCB to allowcompressed data bands to pass from the USB or ISI through the SCB toSoPEC DRAM. FIG. 5 shows an example data flow for a page destined to beprinted by a single SoPEC. Band usage information is generated by theindividual SoPECs and passed back to the host.

SoPEC has an addressing mechanism that permits circular band memoryallocation, thus facilitating easy memory management. However it is notstrictly necessary that all bands be stored together. As long as theappropriate registers in SoPEC are set up for each band, and a givenband is contiguous, the memory can be allocated in any way.

Print Engine Example Page Format

The format is generated by software in the host PC and interpreted byembedded software in SoPEC. This section indicates the type ofinformation in a page format structure, but implementations need not belimited to this format. The host PC can optionally perform the majorityof the header processing.

The compressed format and the print engines are designed to allowreal-time page expansion during printing, to ensure that printing isnever interrupted in the middle of a page due to data underrun.

The page format described here is for a single black bi-level layer, acontone layer, and a Netpage tag layer. The black bi-level layer isdefined to composite over the contone layer. The black bi-level layerconsists of a bitmap containing a 1-bit opacity for each pixel. Thisblack layer matte has a resolution which is an integer or non-integerfactor of the printer's dot resolution. The highest supported resolutionis 1600 dpi, i.e. the printer's full dot resolution.

The contone layer, optionally passed in as YCrCb, consists of a 24-bitCMY or 32-bit CMYK color for each pixel. This contone image has aresolution which is an integer or non-integer factor of the printer'sdot resolution. The requirement for a single SoPEC is to support 1 sideper 2 seconds A4/Letter printing at a resolution of 267 ppi, i.e.one-sixth the printer's dot resolution. Non-integer scaling can beperformed on both the contone and bi-level images. Only integer scalingcan be performed on the tag data. The black bi-level layer and thecontone layer are both in compressed form for efficient storage in theprinter's internal memory.

Page Structure

A single SoPEC is able to print with full edge bleed for Letter and A3via different stitch part combinations of the bi-lithic printhead. Itimposes no margins and so has a printable page area which corresponds tothe size of its paper. The target page size is constrained by theprintable page area, less the explicit (target) left and top marginsspecified in the page description. These relationships are illustratedbelow.

Compressed Page Format

Apart from being implicitly defined in relation to the printable pagearea, each page description is complete and self-contained. There is nodata stored separately from the page description to which the pagedescription refers.¹ The page description consists of a page headerwhich describes the size and resolution of the page, followed by one ormore page bands which describe the actual page content. ¹SoPEC relies ondither matrices and tag structures to have already been set up, butthese are not considered to be part of a general page format. It istrivial to extend the page format to allow exact specification of dithermatrices and tag structures.

Page Header

Table 3 shows an example format of a page header.

TABLE 3 Page header format Field Format Description signature 16-bitPage header format signature. integer Version 16-bit Page header formatversion number. integer structure size 16-bit Size of page header.integer band count 16-bit Number of bands specified for this page.integer target resolution 16-bit Resolution of target page. This isalways 1600 for the (dpi) integer Memjet printer. target page width16-bit Width of target page, in dots. integer target page height 32-bitHeight of target page, in dots. integer target left margin 16-bit Widthof target left margin, in dots, for black and for black and integercontone. contone target top margin for 16-bit Height of target topmargin, in dots, for black and black and contone integer contone. targetright margin 16-bit Width of target right margin, in dots, for black andfor black and integer contone. contone Target bottom 16-bit Height oftarget bottom margin, in dots, for black and margin for black integercontone. and contone target left margin 16-bit Width of target leftmargin, in dots, for tags. for tags integer target top margin for 16-bitHeight of target top margin, in dots, for tags. tags integer targetright margin 16-bit Width of target right margin, in dots, for tags. fortags integer target bottom 16-bit Height of target bottom margin, indots, for tags. margin for tags integer Generate tags 16-bit Specifieswhether to generate tags for this page (0 - integer no, 1 - yes). fixedtag data 128 bit This is only valid if generate tags is set. integer tagvertical scale 16-bit Scale factor in vertical direction from tag datafactor integer resolution to target resolution. Valid range = 1-511.Integer scaling only tag horizontal scale 16-bit Scale factor inhorizontal direction from tag data factor integer resolution to targetresolution. Valid range = 1-511. Integer scaling only. bi-level layer16-bit Scale factor in vertical direction from bi-level vertical scalefactor integer resolution to target resolution (must be 1 or greater).May be non-integer. Expressed as a fraction with upper 8-bits thenumerator and the lower 8 bits the denominator. bi-level layer 16-bitScale factor in horizontal direction from bi-level horizontal scalefactor integer resolution to target resolution (must be 1 or greater).May be non-integer. Expressed as a fraction with upper 8-bits thenumerator and the lower 8 bits the denominator. bi-level layer page16-bit Width of bi-level layer page, in pixels. width integer bi-levellayer page 32-bit Height of bi-level layer page, in pixels. heightinteger contone flags 16 bit Defines the color conversion that isrequired for the integer JPEG data. Bits 2-0 specify how many contoneplanes there are (e.g. 3 for CMY and 4 for CMYK). Bit 3 specifieswhether the first 3 color planes need to be converted back from YCrCb toCMY. Only valid if b2-0 = 3 or 4; 0 - no conversion, leave JPEG colorsalone; 1 - color convert. Bits 7-4 specifies whether the YCrCb wasgenerated directly from CMY, or whether it was converted to RGB firstvia the step: R = 255-C, G = 255-M, B = 255-Y. Each of the color planescan be individually inverted. Bit 4: 0 - do not invert color plane 0;1 - invert color plane 0. Bit 5: 0 - do not invert color plane 1; 1 -invert color plane 1. Bit 6: 0 - do not invert color plane 2; 1 - invertcolor plane 2. Bit 7: 0 - do not invert color plane 3; 1 - invert colorplane 3. Bit 8 specifies whether the contone data is JPEG compressed ornon-compressed: 0 - JPEG compressed; 1 - non-compressed. The remainingbits are reserved (0). Contone vertical 16-bit Scale factor in verticaldirection from contone channel scale factor integer resolution to targetresolution. Valid range = 1-255. May be non-integer. Expressed as afraction with upper 8-bits the numerator and the lower 8 bits thedenominator. Contone horizontal 16-bit Scale factor in horizontaldirection from contone scale factor integer channel resolution to targetresolution. Valid range = 1-255. May be non-integer. Expressed as afraction with upper 8-bits the numerator and the lower 8 bits thedenominator. Contone page width 16-bit Width of contone page, in contonepixels. integer Contone page height 32-bit Height of contone page, incontone pixels. integer Reserved up to 128 Reserved and 0 pads out pageheader to multiple of bytes 128 bytes.

The page header contains a signature and version which allow the CPU toidentify the page header format. If the signature and/or version aremissing or incompatible with the CPU, then the CPU can reject the page.

The contone flags define how many contone layers are present, whichtypically is used for defining whether the contone layer is CMY or CMYK.Additionally, if the color planes are CMY, they can be optionally storedas YCrCb, and further optionally color space converted from CMY directlyor via RGB. Finally the contone data is specified as being either JPEGcompressed or non-compressed.

The page header defines the resolution and size of the target page. Thebi-level and contone layers are clipped to the target page if necessary.This happens whenever the bi-level or contone scale factors are notfactors of the target page width or height.

The target left, top, right and bottom margins define the positioning ofthe target page within the printable page area. The tag parametersspecify whether or not Netpage tags should be produced for this page andwhat orientation the tags should be produced at (landscape or portraitmode). The fixed tag data is also provided. The contone, bi-level andtag layer parameters define the page size and the scale factors.

Band Format

Table 4 shows the format of the page band header.

TABLE 4 Band header format Field Format Description 7signature 16-bitinteger Page band header format signature. Version 16-bit integer Pageband header format version number. structure size 16-bit integer Size ofpage band header. bi-level layer band height 16-bit integer Height ofbi-level layer band, in black pixels. bi-level layer band data 32-bitinteger Size of bi-level layer band data, in bytes. size Contone bandheight 16-bit integer Height of contone band, in contone pixels. Contoneband data size 32-bit integer Size of contone plane band data, in bytes.tag band height 16-bit integer Height of tag band, in dots. tag banddata size 32-bit integer Size of unencoded tag data band, in bytes. Canbe 0 which indicates that no tag data is provided. Reserved up to 128Reserved and 0 pads out band header to bytes multiple of 128 bytes.

The bi-level layer parameters define the height of the black band, andthe size of its compressed band data. The variable-size black datafollows the page band header. The contone layer parameters define theheight of the contone band, and the size of its compressed page data.The variable-size contone data follows the black data. The tag band datais the set of variable tag data half-lines as required by the tagencoder. The format of the tag data is found in. The tag band datafollows the contone data. Table 5 shows the format of the variable-sizecompressed band data which follows the page band header.

TABLE 5 Page band data format Field Format Description Black dataModified G4 facsimile Compressed bi-level layer. bitstream Contone JPEGbytestream Compressed contone datalayer. data Tag data Tag data arrayTag data format. map

The start of each variable-size segment of band data should be alignedto a 256-bit DRAM word boundary.

Bi-Level Data Compression

The (typically 1600 dpi) black bi-level layer is losslessly compressedusing Silverbrook Modified Group 4 (SMG4) compression which is a versionof Group 4 Facsimile compression without Huffman and with simplified runlength encodings. Typically compression ratios exceed 10:1.

SMG4 has a pass through mode to cope with local negative compression.Pass through mode is activated by a special run-length code. Passthrough mode continues to either end of line or for a pre-programmednumber of bits, whichever is shorter. The special run-length code isalways executed as a run-length code, followed by pass through. The passthrough escape code is a medium length run-length w. Since thecompression is a bitstream, the encodings are read right (leastsignificant bit) to left (most significant bit). The run lengths areread in the same way (least significant bit at the right to mostsignificant bit at the left).

Each band of bi-level data is optionally self contained. The first lineof each band therefore is based on a ‘previous’ blank line or the lastline of the previous band.

Group 3 and 4 Facsimile Compression

The Group 3 Facsimile compression algorithm losslessly compressesbi-level data for transmission over slow and noisy telephone lines. Thebi-level data represents scanned black text and graphics on a whitebackground, and the algorithm is tuned for this class of images (it isexplicitly not tuned, for example, for halftoned bi-level images). The1D Group 3 algorithm runlength-encodes each scanline and thenHuffman-encodes the resulting runlengths. Runlengths in the range 0 to63 are coded with terminating codes. Runlengths in the range 64 to 2623are coded with make-up codes, each representing a multiple of 64,followed by a terminating code.

Runlengths exceeding 2623 are coded with multiple make-up codes followedby a terminating code. The Huffman tables are fixed, but are separatelytuned for black and white runs (except for make-up codes above 1728,which are common). When possible, the 2D Group 3 algorithm encodes ascanline as a set of short edge deltas (0, ±1, ±2, ±3) with reference tothe previous scanline. The delta symbols are entropy-encoded (so thatthe zero delta symbol is only one bit long etc.) Edges within a2D-encoded line which can't be delta-encoded are runlength-encoded, andare identified by a prefix. 1D- and 2D-encoded lines are markeddifferently. 1D-encoded lines are generated at regular intervals,whether actually required or not, to ensure that the decoder can recoverfrom line noise with minimal image degradation. 2D Group 3 achievescompression ratios of up to 6:1.

The Group 4 Facsimile algorithm losslessly compresses bi-level data fortransmission over error-free communications lines (i.e. the lines aretruly error-free, or error-correction is done at a lower protocollevel). The Group 4 algorithm is based on the 2D Group 3 algorithm, withthe essential modification that since transmission is assumed to beerror-free, 1D-encoded lines are no longer generated at regularintervals as an aid to error-recovery. Group 4 achieves compressionratios ranging from 20:1 to 60:1 for the CCITT set of test images.

The design goals and performance of the Group 4 compression algorithmqualify it as a compression algorithm for the bi-level layers. However,its Huffman tables are tuned to a lower scanning resolution (100-400dpi), and it encodes runlengths exceeding 2623 awkwardly.

Contone Data Compression

The contone layer (CMYK) is either a non-compressed bytestream or iscompressed to an interleaved JPEG bytestream. The JPEG bytestream iscomplete and self-contained. It contains all data required fordecompression, including quantization and Huffman tables.

The contone data is optionally converted to YCrCb before beingcompressed (there is no specific advantage in color-space converting ifnot compressing). Additionally, the CMY contone pixels are optionallyconverted (on an individual basis) to RGB before color conversion usingR=255-C, G=255-M, B=255-Y. Optional bitwise inversion of the K plane mayalso be performed. Note that this CMY to RGB conversion is not intendedto be accurate for display purposes, but rather for the purposes oflater converting to YCrCb. The inverse transform will be applied beforeprinting.

JPEG Compression

The JPEG compression algorithm lossily compresses a contone image at aspecified quality level. It introduces imperceptible image degradationat compression ratios below 5:1, and negligible image degradation atcompression ratios below 10:1.

JPEG typically first transforms the image into a color space whichseparates luminance and chrominance into separate color channels. Thisallows the chrominance channels to be subsampled without appreciableloss because of the human visual system's relatively greater sensitivityto luminance than chrominance. After this first step, each color channelis compressed separately.

The image is divided into 8×8 pixel blocks. Each block is thentransformed into the frequency domain via a discrete cosine transform(DCT). This transformation has the effect of concentrating image energyin relatively lower-frequency coefficients, which allowshigher-frequency coefficients to be more crudely quantized. Thisquantization is the principal source of compression in JPEG. Furthercompression is achieved by ordering coefficients by frequency tomaximize the likelihood of adjacent zero coefficients, and thenrunlength-encoding runs of zeroes. Finally, the runlengths and non-zerofrequency coefficients are entropy coded. Decompression is the inverseprocess of compression.

Non-Compressed Format

If the contone data is non-compressed, it must be in a block-basedformat bytestream with the same pixel order as would be produced by aJPEG decoder. The bytestream therefore consists of a series of 8×8 blockof the original image, starting with the top left 8×8 block, and workinghorizontally across the page (as it will be printed) until the toprightmost 8×8 block, then the next row of 8×8 blocks (left to right) andso on until the lower row of 8×8 blocks (left to right). Each 8×8 blockconsists of 64 8-bit pixels for color plane 0 (representing 8 rows of 8pixels in the order top left to bottom right) followed by 64 8-bitpixels for color plane 1 and so on for up to a maximum of 4 colorplanes. If the original image is not a multiple of 8 pixels in X or Y,padding must be present (the extra pixel data will be ignored by thesetting of margins).

Compressed Format

If the contone data is compressed the first memory band contains JPEGheaders (including tables) plus MCUs (minimum coded units). The ratio ofspace between the various color planes in the JPEG stream is 1:1:1:1. Nosubsampling is permitted. Banding can be completely arbitrary i.e therecan be multiple JPEG images per band or 1 JPEG image divided overmultiple bands. The break between bands is only memory alignment based.

Conversion of RGB to YCrCb (in RIP)

YCrCb is defined as per CCIR 601-1 except that Y, Cr and Cb arenormalized to occupy all 256 levels of an 8-bit binary encoding and takeaccount of the actual hardware implementation of the inverse transformwithin SoPEC. The exact color conversion computation is as follows:

Y*=(9805/32768)R+(19235/32768)G+(3728/32768)B

Cr*=(16375/32768)R−(13716/32768)G−(2659/32768)B+128

Cb*=−(5529/32768)R−(10846/32768)G+(16375/32768)B+128

Y, Cr and Cb are obtained by rounding to the nearest integer. There isno need for saturation since ranges of Y*, Cr* and Cb* after roundingare [0-255], [1-255] and [1-255] respectively.Note that Full Accuracy is Possible with 24 Bits.

SoPEC ASIC

The Small Office Home Office Print Engine Controller (SoPEC) is a pagerendering engine ASIC that takes compressed page images as input, andproduces decompressed page images at up to 6 channels of bi-level dotdata as output. The bi-level dot data is generated for the Memjetbi-lithic printhead. The dot generation process takes account ofprinthead construction, dead nozzles, and allows for fixativegeneration.

A single SoPEC can control 2 bi-lithic printheads and up to 6 colorchannels at 10,000 lines/sec², equating to 30 pages per minute. A singleSoPEC can perform full-bleed printing of A3, A4 and Letter pages. The 6channels of colored ink are the expected maximum in a consumer SOHO, oroffice Bi-lithic printing environment:

-   -   CMY, for regular color printing.    -   K, for black text, line graphics and gray-scale printing.    -   IR (infrared), for Netpage-enabled applications.    -   F (fixative), to enable printing at high speed. Because the        bi-lithic printer is capable of printing so fast, a fixative may        be required to enable the ink to dry before the page touches the        page already printed. Otherwise the pages may bleed on each        other. In low speed printing environments the fixative may not        be required. ²10,000 lines per second equates to 30 A4/Letter        pages per minute at 1600 dpi

SoPEC is color space agnostic. Although it can accept contone data asCMYX or RGBX, where X is an optional 4th channel, it also can acceptcontone data in any print color space. Additionally, SoPEC provides amechanism for arbitrary mapping of input channels to output channels,including combining dots for ink optimization, generation of channelsbased on any number of other channels etc. However, inputs are typicallyCMYK for contone input, K for the bi-level input, and the optionalNetpage tag dots are typically rendered to an infra-red layer. Afixative channel is typically generated for fast printing applications.

SoPEC is resolution agnostic. It merely provides a mapping between inputresolutions and output resolutions by means of scale factors. Theexpected output resolution is 1600 dpi, but SoPEC actually has noknowledge of the physical resolution of the Bi-lithic printhead.

SoPEC is page-length agnostic. Successive pages are typically split intobands and downloaded into the page store as each band of information isconsumed and becomes free. SoPEC provides an interface forsynchronization with other SoPECs. This allows simple multi-SoPECsolutions for simultaneous A3/A4/Letter duplex printing. However, SoPECis also capable of printing only a portion of a page image. Combiningsynchronization functionality with partial page rendering allowsmultiple SoPECs to be readily combined for alternative printingrequirements including simultaneous duplex printing and wide formatprinting.

Printing Rates

The required printing rate for SoPEC is 30 sheets per minute with aninter-sheet spacing of 4 cm. To achieve a 30 sheets per minute printrate, this requires: 300 mm×63 (dot/mm)/2 sec=105.8 μseconds per line,with no inter-sheet gap; 340 mm×63 (dot/mm)/2 sec=93.3 μseconds perline, with a 4 cm inter-sheet gap. A printline for an A4 page consistsof 13824 nozzles across the page. At a system clock rate of 160 MHz13824 dots of data can be generated in 86.4 μseconds. Therefore data canbe generated fast enough to meet the printing speed requirement. It isnecessary to deliver this print data to the print-heads.

Printheads can be made up of 5:5, 6:4, 7:3 and 8:2 inch printheadcombinations. Print data is transferred to both print heads in a pairsimultaneously. This means the longest time to print a line isdetermined by the time to transfer print data to the longest printsegment. There are 9744 nozzles across a 7 inch printhead. The printdata is transferred to the printhead at a rate of 106 MHz (⅔ of thesystem clock rate) per color plane. This means that it will take 91.9 μsto transfer a single line for a 7:3 printhead configuration. So we canmeet the requirement of 30 sheets per minute printing with a 4 cm gapwith a 7:3 printhead combination. There are 11160 across an 8 inchprinthead. To transfer the data to the printhead at 106 MHz will take105.3 μs. So an 8:2 printhead combination printing with an inter-sheetgap will print slower than 30 sheets per minute.

SoPEC Basic Architecture

From the highest point of view the SoPEC device consists of 3 distinctsubsystems: CPU Subsystem; DRAM Subsystem; and Print Engine Pipeline(PEP) Subsystem. See FIG. 6 for a block level diagram of SoPEC.

CPU Subsystem

The CPU subsystem controls and configures all aspects of the othersubsystems. It provides general support for interfacing andsynchronising the external printer with the internal print engine. Italso controls the low speed communication to the QA chips. The CPUsubsystem contains various peripherals to aid the CPU, such as GPIO(includes motor control), interrupt controller, LSS Master and generaltimers. The Serial Communications Block (SCB) on the CPU subsystemprovides a full speed USB 1.1 interface to the host as well as an InterSoPEC Interface (ISI) to other SoPEC devices.

DRAM Subsystem

The DRAM subsystem accepts requests from the CPU, Serial CommunicationsBlock (SCB) and blocks within the PEP subsystem. The DRAM subsystem (inparticular the DIU) arbitrates the various requests and determines whichrequest should win access to the DRAM. The DIU arbitrates based onconfigured parameters, to allow sufficient access to DRAM for allrequesters. The DIU also hides the implementation specifics of the DRAMsuch as page size, number of banks, refresh rates etc.

Print Engine Pipeline (PEP) Subsystem

The Print Engine Pipeline (PEP) subsystem accepts compressed pages fromDRAM and renders them to bi-level dots for a given print line destinedfor a printhead interface that communicates directly with up to 2segments of a bi-lithic printhead.

The first stage of the page expansion pipeline is the CDU, LBD and TE.The CDU expands the JPEG-compressed contone (typically CMYK) layer, theLBD expands the compressed bi-level layer (typically K), and the TEencodes Netpage tags for later rendering (typically in IR or K ink). Theoutput from the first stage is a set of buffers: the CFU, SFU, and TFU.The CFU and SFU buffers are implemented in DRAM.

The second stage is the HCU, which dithers the contone layer, andcomposites position tags and the bi-level spot0 layer over the resultingbi-level dithered layer. A number of options exist for the way in whichcompositing occurs. Up to 6 channels of bi-level data are produced fromthis stage. Note that not all 6 channels may be present on theprinthead. For example, the printhead may be CMY only, with K pushedinto the CMY channels and IR ignored. Alternatively, the position tagsmay be printed in K if IR ink is not available (or for testingpurposes).

The third stage (DNC) compensates for dead nozzles in the printhead bycolor redundancy and error diffusing dead nozzle data into surroundingdots.

The resultant bi-level 6 channel dot-data (typically CMYK-IRF) isbuffered and written out to a set of line buffers stored in DRAM via theDWU. Finally, the dot-data is loaded back from DRAM, and passed to theprinthead interface via a dot FIFO. The dot FIFO accepts data from theLLU at the system clock rate (pclk), while the PHI removes data from theFIFO and sends it to the printhead at a rate of ⅔ times the system clockrate.

SoPEC Block Description

Looking at FIG. 6, the various units are described in Table 6 summaryform:

TABLE 6 Units within SoPEC Subsystem Unit Description DRAM DIU Providesthe interface for DRAM read and write access for the various SoPECunits, CPU and the SCB block. The DIU provides arbitration betweencompeting units controls DRAM access. DRAM 20 Mbits of embedded DRAM,CPU CPU CPU for system configuration and control MMU Limits access tocertain memory address areas in CPU user mode RDU Facilitates theobservation of the contents of most of the CPU addressable registers inSoPEC in addition to some pseudo-registers in realtime. TIM Containswatchdog and general system timers LSS Low level controller forinterfacing with the QA chips GPIO General IO controller, with built-inMotor control unit, LED pulse units and de-glitch circuitry ROM 16KBytes of System Boot ROM code ICU General Purpose interrupt controllerwith configurable priority, and masking. CPR Central Unit forcontrolling and generating the system clocks and resets and powerdownmechanisms PSS Storage retained while system is powered down USB USBdevice controller for interfacing with the host USB. ISI ISI controllerfor data and control communication with other SoPEC's in a multi-SoPECsystem SCB Contains both the USB and ISI blocks. PEP PCU Providesexternal CPU with the means to read and write PEP Unit registers, andread and write DRAM in single 32-bit chunks. CDU Expands JPEG compressedcontone layer and writes decompressed contone to DRAM CFU Provides linebuffering between CDU and HCU LBD Expands compressed bi-level layer. SFUProvides line buffering between LBD and HCU TE Encodes tag data intoline of tag dots. TFU Provides tag data storage between TE and HCU HCUDithers contone layer and composites the bi-level spot 0 and positiontag dots. DNC Compensates for dead nozzles by color redundancy and errordiffusing dead nozzle data into surrounding dots. DWU Writes out the 6channels of dot data for a given printline to the line store DRAM LLUReads the expanded page image from line store, formatting the dataappropriately for the bi-lithic printhead. PHI Is responsible forsending dot data to the bi-lithic printheads and for providing linesynchronization between multiple SoPECs. Also provides test interface toprinthead such as temperature monitoring and Dead Nozzle Identification.

SoPEC Use Cases

There are many miscellaneous use cases such as the following examples.Software running on the SoPEC CPU or host will decide on what actions totake in these scenarios. For example, a sequence is typically performedwhen dead nozzle information in a Dead-nozzle table needs to be updatedby performing a printhead dead nozzle test: 1) Run printhead nozzle testsequence; 2) Either host or SoPEC CPU converts dead nozzle informationinto dead nozzle table; 3) Store dead nozzle table on host; and 4) Writedead nozzle table to SoPEC DRAM.

Dram Subsystem DRAM Interface Unit (DIU)

FIG. 8 shows how the DIU provides the interface between the on-chip 20Mbit embedded DRAM and the rest of SoPEC. In addition to outlining thefunctionality of the DIU, this chapter provides a top-level overview ofthe memory storage and access patterns of SoPEC and the bufferingrequired in the various SoPEC blocks to support those accessrequirements.

The main functionality of the DIU is to arbitrate between requests foraccess to the embedded DRAM and provide read or write accesses to therequesters. The DIU must also implement the initialisation sequence andrefresh logic for the embedded DRAM. The arbitration scheme uses a fullyprogrammable timeslot mechanism for non-CPU requesters to meet thebandwidth and latency requirements for each unit, with unused slotsre-allocated to provide best effort accesses. The CPU is allowed highpriority access, giving it minimum latency, but allowing bounds to beplaced on its bandwidth consumption.

The interface between the DIU and the SoPEC requesters is similar to theinterface on PEC1 i.e. separate control, read data and write databusses. The embedded DRAM is used principally to store:

-   -   CPU program code and data.    -   PEP (re)programming commands.    -   Compressed pages containing contone, bi-level and raw tag data        and header information.    -   Decompressed contone and bi-level data.    -   Dotline store during a print.    -   Print setup information such as tag format structures, dither        matrices and dead nozzle information.

Contone Decoder Unit (CDU)

The Contone Decoder Unit (CDU) is responsible for performing theoptional decompression of the contone data layer.

The input to the CDU is up to 4 planes of compressed contone data inJPEG interleaved format. This will typically be 3 planes, representing aCMY contone image, or 4 planes representing a CMYK contone image. TheCDU must support a page of A4 length (11.7 inches) and Letter width (8.5inches) at a resolution of 267 ppi in 4 colors and a print speed of 1side per 2 seconds.

The CDU and the other page expansion units support the notion of pagebanding. A compressed page is divided into one or more bands, with anumber of bands stored in memory. As a band of the page is consumed forprinting a new band can be downloaded. The new band may be for thecurrent page or the next page. Band-finish interrupts have been providedto notify the CPU of free buffer space.

The compressed contone data is read from the on-chip DRAM. The output ofthe CDU is the decompressed contone data, separated into planes. Thedecompressed contone image is written to a circular buffer in DRAM withan expected minimum size of 12 lines and a configurable maximum. Thedecompressed contone image is subsequently read a line at a time by theCFU, optionally color converted, scaled up to 1600 ppi and then passedon to the HCU for the next stage in the printing pipeline. The CDU alsooutputs a cdu_finishedband control flag indicating that the CDU hasfinished reading a band of compressed contone data in DRAM and that areaof DRAM is now free. This flag is used by the PCU and is available as aninterrupt to the CPU.

Storage Requirements for Decompressed Contone Data in Dram

A single SoPEC must support a page of A4 length (11.7 inches) and Letterwidth (8.5 inches) at a resolution of 267 ppi in 4 colors and a printspeed of 1 side per 2 seconds. The printheads specified in the Bi-lithicPrinthead Specification [2] have 13824 nozzles per color to provide fullbleed printing for A4 and Letter. At 267 ppi, there are 2304 contonepixels³ per line represented by 288 JPEG blocks per color. However eachof these blocks actually stores data for 8 lines, since a single JPEGblock is 8×8 pixels. The CDU produces contone data for 8 lines inparallel, while the HCU processes data linearly across a line on a lineby line basis. The contone data is decoded only once and then bufferedin DRAM. This means we require two sets of 8 buffer-lines—one set of 8buffer lines is being consumed by the CFU while the other set of 8buffer lines is being generated by the CDU. ³Pixels may be 8, 16, 24 or32 bits depending on the number of color planes (8-bits per color)

The buffer requirement can be reduced by using a 1.5 buffering scheme,where the CDU fills 8 lines while the CFU consumes 4 lines. The bufferspace required is a minimum of 12 line stores per color, for a totalspace of 108 KBytes⁴. A circular buffer scheme is employed whereby theCDU may only begin to write a line of JPEG blocks (equals 8 lines ofcontone data) when there are 8-lines free in the buffer. Once the full 8lines have been written by the CDU, the CFU may now begin to read themon a line by line basis. ⁴12 lines×4 colors×2304 bytes (assumes 267 ppi,4 color, full bleed A4/Letter)

This reduction in buffering comes with the cost of an increased peakbandwidth requirement for the CDU write access to DRAM. The CDU must beable to write the decompressed contone at twice the rate at which theCFU reads the data. To allow for trade-offs to be made between peakbandwidth and amount of storage, the size of the circular buffer isconfigurable. For example, if the circular buffer is configured to be 16lines it behaves like a double-buffer scheme where the peak bandwidthrequirements of the CDU and CFU are equal. An increase over 16 linesallows the CDU to write ahead of the CFU and provides it with a marginto cope with very poor local compression ratios in the image.

SoPEC should also provide support for A3 printing and printing atresolutions above 267 ppi. This increases the storage requirement forthe decompressed contone data (buffer) in DRAM. Table 7 gives thestorage requirements for the decompressed contone data at some samplecontone resolutions for different page sizes. It assumes 4 color planesof contone data and a 1.5 buffering scheme.

TABLE 7 Storage requirements for decompressed contone data (buffer)Contone Scale Storage required Page size resolution (ppi) factor^(a)Pixels per line (kBytes) A4/Letter^(b) 267 6 2304 108^(d) 400 4 3456 162800 2 6912 324 A3^(c) 267 6 3248 152.25 400 4 4872 228.37 800 2 9744456.75 ^(a)Required for CFU to convert to final output at 1600 dpi^(b)Bi-lithic printhead has 13824 nozzles per color providing full bleedprinting for A4/Letter ^(c)Bi-lithic printhead has 19488 nozzles percolor providing full bleed printing for A3 ^(d)12 lines × 4 colors ×2304 bytes.

Decompression Performance Requirements

The JPEG decoder core can produce a single color pixel every systemclock (pclk) cycle, making it capable of decoding at a peak output rateof 8 bits/cycle. SoPEC processes 1 dot (bi-level in 6 colors) per systemclock cycle to achieve a print speed of 1 side per 2 seconds for fullbleed A4/Letter printing. The CFU replicates pixels a scale factor (SF)number of times in both the horizontal and vertical directions toconvert the final output to 1600 ppi. Thus the CFU consumes a 4 colorpixel (32 bits) every SF×SF cycles. The 1.5 buffering scheme means thatthe CDU must write the data at twice this rate. With support for 4colors at 267 ppi, the decompression output bandwidth requirement is1.78 bits/cycle⁵. ⁵2×((4 colors×8 bits)/(6×6 cycles))=1.78 bits/cycle

The JPEG decoder is fed directly from the main memory via the DRAMinterface. The amount of compression determines the input bandwidthrequirements for the CDU. As the level of compression increases, thebandwidth decreases, but the quality of the final output image can alsodecrease. Although the average compression ratio for contone data isexpected to be 10:1, the average bandwidth allocated to the CDU allowsfor a local minimum compression ratio of 5:1 over a single line of JPEGblocks. This equates to a peak input bandwidth requirement of 0.36bits/cycle for 4 colors at 267 ppi, full bleed A4/Letter printing at 1side per 2 seconds.

Table 8 gives the decompression output bandwidth requirements fordifferent resolutions of contone data to meet a print speed of 1 sideper 2 seconds. Higher resolution requires higher bandwidth and largerstorage for decompressed contone data in DRAM. A resolution of 400 ppicontone data in 4 colors requires 4 bits/cycle⁶, which is practicalusing a 1.5 buffering scheme. However, a resolution of 800 ppi wouldrequire a double buffering scheme (16 lines) so the CDU only has tomatch the CFU consumption rate. In this case the decompression outputbandwidth requirement is 8 bits/cycle⁷, the limiting factor being theoutput rate of the JPEG decoder core. ⁶2×((4 colors×8 bits)/(4×4cycles))=4 bits/cycle⁷(4 colors×8 bits)/(2×2 cycles)=8 bits/cycle

TABLE 8 CDU performance requirements for full bleed A4/Letter printingat 1 side/2 secs Contone resolution Decompression output bandwidth (ppi)Scale factor requirement (bits/cycle)^(a) 267 6 1.78 400 4 4 800 2 8^(b)^(a)Assumes 4 color pixel contone data and a 12 line buffer. ^(b)Scalefactor 2 requires at least a 16 line buffer.

Data Flow

FIG. 9 shows the general data flow for contone data—compressed contoneplanes are read from DRAM by the CDU, and the decompressed contone datais written to the 12-line circular buffer in DRAM. The line buffers aresubsequently read by the CFU.

The CDU allows the contone data to be passed directly on, which will bethe case if the color represented by each color plane in the JPEG imageis an available ink. For example, the four colors may be C, M, Y, and K,directly represented by CMYK inks. The four colors may represent gold,metallic green etc. for multi-SoPEC printing with exact colors.

However JPEG produces better compression ratios for a given visiblequality when luminance and chrominance channels are separated. WithCMYK, K can be considered to be luminance, but C, M, and Y each containluminance information, and so would need to be compressed withappropriate luminance tables. We therefore provide the means by whichCMY can be passed to SoPEC as YCrCb. K does not need color conversion.When being JPEG compressed, CMY is typically converted to RGB, then toYCrCb and then finally JPEG compressed. At decompression, the YCrCb datais obtained and written to the decompressed contone store by the CDU.This is read by the CFU where the YCrCb can then be optionally colorconverted to RGB, and finally back to CMY.

The external RIP provides conversion from RGB to YCrCb, specifically tomatch the actual hardware implementation of the inverse transform withinSoPEC, as per CCIR 601-2 [24] except that Y, Cr and Cb are normalized tooccupy all 256 levels of an 8-bit binary encoding.

The CFU provides the translation to either RGB or CMY. RGB is includedsince it is a necessary step to produce CMY, and some printers increasetheir color gamut by including RGB inks as well as CMYK.

Halftoner Compositor Unit (HCU)

The Halftoner Compositor Unit (HCU) produces dots for each nozzle in thedestination printhead taking account of the page dimensions (includingmargins). The spot data and tag data are received in bi-level form whilethe pixel contone data received from the CFU must be dithered to abi-level representation. The resultant 6 bi-level planes for each dotposition on the page are then remapped to 6 output planes and output dotat a time (6 bits) to the next stage in the printing pipeline, namelythe dead nozzle compensator (DNC).

Data Flow

FIG. 11 shows a simple dot data flow high level block diagram of theHCU. The HCU reads contone data from the CFU, bi-level spot data fromthe SFU, and bi-level tag data from the TFU. Dither matrices are readfrom the DRAM via the DIU. The calculated output dot (6 bits) is read bythe DNC.

The HCU is given the page dimensions (including margins), and is onlystarted once for the page. It does not need to be programmed in betweenbands or restarted for each band. The HCU will stall appropriately ifits input buffers are starved. At the end of the page the HCU willcontinue to produce 0 for all dots as long as data is requested by theunits further down the pipeline (this allows later units to convenientlyflush pipelined data).

The HCU performs a linear processing of dots calculating the 6-bitoutput of a dot in each cycle. The mapping of 6 calculated bits to 6output bits for each dot allows for such example mappings as compositingof the spot0 layer over the appropriate contone layer (typically black),the merging of CMY into K (if K is present in the printhead), thesplitting of K into CMY dots if there is no K in the printhead, and thegeneration of a fixative output bitstream.

Dram Storage Requirements

SoPEC allows for a number of different dither matrix configurations upto 256 bytes wide. The dither matrix is stored in DRAM. Using either asingle or double-buffer scheme a line of the dither matrix must be readin by the HCU over a SoPEC line time. SoPEC must produce 13824 dots perline for A4/Letter printing which takes 13824 cycles.

The following give the storage and bandwidths requirements for some ofthe possible configurations of the dither matrix.

-   -   4 Kbyte DRAM storage required for one 64×64 (preferred) byte        dither matrix    -   6.25 Kbyte DRAM storage required for one 80×80 byte dither        matrix    -   16 Kbyte DRAM storage required for four 64×64 byte dither        matrices    -   64 Kbyte DRAM storage required for one 256×256 byte dither        matrix

It takes 4 or 8 read accesses to load a line of dither matrix into thedither matrix buffer, depending on whether we're using a single ordouble buffer (configured by DoubleLineBuff register).

Implementation

A block diagram of the HCU is given in FIG. 12.

Control Unit

The control unit is responsible for controlling the overall flow of theHCU. It is responsible for determining whether or not a dot will begenerated in a given cycle, and what dot will actually begenerated—including whether or not the dot is in a margin area, and whatdither cell values should be used at the specific dot location. A blockdiagram of the control unit is shown in FIG. 13.

The inputs to the control unit are a number of avail flags specifyingwhether or not a given dotgen unit is capable of supplying ‘real’ datain this cycle. The term ‘real’ refers to data generated from externalsources, such as contone line buffers, bi-level line buffers, and tagplane buffers. Each dotgen unit informs the control unit whether or nota dot can be generated this cycle from real data. It must also checkthat the DNC is ready to receive data.

The contone/spot margin unit is responsible for determining whether thecurrent dot coordinate is within the target contone/spot margins, andthe tag margin unit is responsible for determining whether the currentdot coordinate is within the target tag margins.

The dither matrix table interface provides the interface to DRAM for thegeneration of dither cell values that are used in the halftoning processin the contone dotgen unit.

Determine Advdot

The HCU does not always require contone planes, bi-level or tag planesin order to produce a page. For example, a given page may not have abi-level layer, or a tag layer. In addition, the contone and bi-levelparts of a page are only required within the contone and bi-level pagemargins, and the tag part of a page is only required within the tag pagemargins. Thus output dots can be generated without contone, bi-level ortag data before the respective top margins of a page has been reached,and 0s are generated for all color planes after the end of the page hasbeen reached (to allow later stages of the printing pipeline to flush).

Consequently the HCU has an AvailMask register that determines which ofthe various input avail flags should be taken notice of during theproduction of a page from the first line of the target page, and aTMMask register that has the same behaviour, but is used in the linesbefore the target page has been reached (i.e. inside the target topmargin area). The dither matrix mask bit TMask[0] is the exception, itapplies to all margins areas not just the top margin. Each bit in theAvailMask refers to a particular avail bit: if the bit in the AvailMaskregister is set, then the corresponding avail bit must be 1 for the HCUto advance a dot. The bit to avail correspondence is shown in Table 9.Care should be taken with TMMask—if the particular data is not availableafter the top margin has been reached, then the HCU will stall. Notethat the avail bits for contone and spot colors are ANDed within_target_age after the target page area has been reached to allow dotproduction in the contone/spot margin areas without needing any data inthe CFU and SFU. The avail bit for tag color is ANDed within_tag_target_page after the target tag page area has been reached toallow dot production in the tag margin areas without needing any data inthe TFU.

TABLE 9 Correspondence between bit in AvailMask and avail flag bit # inAvailMask avail flag description 0 dm_avail dither matrix data available1 cp_avail contone pixels available 2 s_avail spot color available 3tp_avail tag plane available

Each of the input avail bits is processed with its appropriate mask bitand the after_top_margin flag (note the dither matrix is the exceptionit is processed with in_target_page). The output bits are ANDed togetheralong with Go and output_buff_full (which specifies whether the outputbuffer is ready to receive a dot in this cycle) to form the output bitadvdot. We also generate wr_advdot. In this way, if the output buffer isfull or any of the specified avail flags is clear, the HCU will stall.When the end of the page is reached, in_page will be deasserted and theHCU will continue to produce 0 for all dots as long as the DNC requestsdata. A block diagram of the determine advdot unit is shown in FIG. 14.

The advance dot block also determines if current page needs dithermatrix, it indicates to the dither matrix table interface block via thedm_read_enable signal. If no dither is required in the margins or in thetarget page then dm_read_enable will be 0 and no dither will be read infor this page.

Position Unit

The position unit is responsible for outputting the position of thecurrent dot (curr_pos, curr_line) and whether or not this dot is thelast dot of a line (advline). Both curr_pos and curr_line are set to 0at reset or when Go transitions from 0 to 1. The position unit relies onthe advdot input signal to advance through the dots on a page. Wheneveran advdot pulse is received, curr_pos gets incremented. If curr_posequals max_dot then an advline pulse is generated as this is the lastdot in a line, curr_line gets incremented, and the curr_pos is reset to0 to start counting the dots for the next line.

The position unit also generates a filtered version of advline calleddm_advline to indicate to the dither matrix pointers to increment to thenext line. The dm_advline is only incremented when dither is requiredfor that line.

if ((after_top_margin AND avail_mask[0]) OR tm_mask[0]) then  dm_advline = advline else   dm_advline = 0

Margin Unit

The responsibility of the margin unit is to determine whether thespecific dot coordinate is within the page at all, within the targetpage or in a margin area (see FIG. 15). This unit is instantiated forboth the contone/spot margin unit and the tag margin unit.

The margin unit takes the current dot and line position, and returnsthree flags.

-   -   the first, in_page is 1 if the current dot is within the page,        and 0 if it is outside the page.    -   the second flag, in_target_page, is 1 if the dot coordinate is        within the target page area of the page, and 0 if it is within        the target top/left/bottom/right margins.    -   the third flag, after_top_margin, is 1 if the current dot is        below the target top margin, and 0 if it is within the target        top margin.

A block diagram of the margin unit is shown in FIG. 16.

Dither Matrix Table Interface

The dither matrix table interface provides the interface to DRAM for thegeneration of dither cell values that are used in the halftoning processin the contone dotgen unit. The control flag dm_read_enable enables thereading of the dither matrix table line structure from DRAM. Ifdm_read_enable is 0, the dither matrix is not specified in DRAM and noDRAM accesses are attempted. The dither matrix table interface has anoutput flag dm_avail which specifies if the current line of thespecified matrix is available. The HCU can be directed to stall whendm_avail is 0 by setting the appropriate bit in the HCU's AvailMask orTMMask registers. When dm_avail is 0 the value in the DitherConstantregister is used as the dither cell values that are output to thecontone dotgen unit.

The dither matrix table interface consists of a state machine thatinterfaces to the DRAM interface, a dither matrix buffer that providesdither matrix values, and a unit to generate the addresses for readingthe buffer. FIG. 17 shows a block diagram of the dither matrix tableinterface. When the HCU first requests data from DRAM, the 64-bits wordtransfer order will be D0,D1,D2,D3. On the second request the transferorder will be D4,D5,D6,D7 and so on for other requests.

Contone Dotgen Unit

The contone dotgen unit is responsible for producing a dot in up to 4color planes per cycle. The contone dotgen unit also produces a cp_availflag which specifies whether or not contone pixels are currentlyavailable, and the output hcu_cfu_advdot to request the CFU to providethe next contone pixel in up to 4 color planes. The block diagram forthe contone dotgen unit is shown in FIG. 20.

A dither unit provides the functionality for dithering a single contoneplane. The contone image is only defined within the contone/spot marginarea. As a result, if the input flag in_target_page is 0, then aconstant contone pixel value is used for the pixel instead of thecontone plane.

The resultant contone pixel is then halftoned. The dither value to beused in the halftoning process is provided by the control data unit. Thehalftoning process involves a comparison between a pixel value and itscorresponding dither value. If the 8-bit contone value is greater thanor equal to the 8-bit dither matrix value a 1 is output. If not, then a0 is output. This means each entry in the dither matrix is in the range1-255 (0 is not used).

Note that constant use is dependant on the in_target_page signal only,if in_target_age is 1 then the cfu_hcu_c*_data should be allowed to passthrough, regardless of the stalling behaviour or the avail_mask/[1]setting. This allows a constant value to be setup on the CFU outputdata, and the use of different constants while inside and outside thetarget page. The hcu_cfu_advdot will always be zero if theavail_mask/[1] is zero.

Spot Dotgen Unit

The spot dotgen unit is responsible for producing a dot of bi-level dataper cycle. It deals with bi-level data (and therefore does not need tohalftone) that comes from the LBD via the SFU. Like the contone layer,the bi-level spot layer is only defined within the contone/spot marginarea. As a result, if input flag in_target_page is 0, then a constantdot value (typically this would be 0) is used for the output dot.

The spot dotgen unit also produces a s_avail flag which specifieswhether or not spot dots are currently available for this spot plane,and the output hcu_sfu_advdot to request the SFU to provide the nextbi-level data value.

Note that constant use is dependant on the in_target_page signal only,if in_target_age is 1 then the sfu_hcu_data should be allowed to passthrough, regardless of the stalling behaviour or the avail_mask setting.This allows a constant value to be setup on the SFU output data, and theuse of different constants while inside and outside the target page. Thehcu_sfu_advdot will always be zero if the avail_mask[2] is zero.

Dot Reorg Unit

The dot reorg unit provides a means of mapping the bi-level dithereddata, the spot0 color, and the tag data to output inks in the actualprinthead. Each dot reorg unit takes a set of 6 1-bit inputs andproduces a single bit output that represents the output dot for thatcolor plane.

The output bit is a logical combination of any or all of the input bits.This allows the spot color to be placed in any output color plane(including infrared for testing purposes), black to be merged into cyan,magenta and yellow (in the case of no black ink in the Memjetprinthead), and tag dot data to be placed in a visible plane. An outputfor fixative can readily be generated by simply combining desired inputbits.

The dot reorg unit contains a 64-bit lookup to allow complete freedomwith regards to mapping. Since all possible combinations of input bitsare accounted for in the 64 bit lookup, a given dot reorg unit can takethe mapping of other reorg units into account. For example, a blackplane reorg unit may produce a 1 only if the contone plane 3 or spotcolor inputs are set (this effectively composites black bi-level overthe contone). A fixative reorg unit may generate a 1 if any 2 of theoutput color planes is set (taking into account the mappings produced bythe other reorg units).

If dead nozzle replacement is to be used, the dot reorg can beprogrammed to direct the dots of the specified color into the mainplane, and 0 into the other. If a nozzle is then marked as dead in theDNC, swapping the bits between the planes will result in 0 in the deadnozzle, and the required data in the other plane.

If dead nozzle replacement is to be used, and there are no tags, the TEcan be programmed with the position of dead nozzles and the resultantpattern used to direct dots into the specified nozzle row. If only fixedbackground TFS is to be used, a limited number of nozzles can bereplaced. If variable tag data is to be used to specify dead nozzles,then large numbers of dead nozzles can be readily compensated for.

The dot reorg unit can be used to average out the nozzle usage when tworows of nozzles share the same ink and tag encoding is not being used.The TE can be programmed to produce a regular pattern (e.g. 0101 on oneline, and 1010 on the next) and this pattern can be used as a directiveas to direct dots into the specified nozzle row.

Each reorg unit contains a 64-bit IOMapping value programmable as two32-bit HCU registers, and a set of selection logic based on the 6-bitdot input (2⁶=64 bits), as shown in FIG. 21. The mapping of input bitsto each of the 6 selection bits is as defined in Table 10.

TABLE 10 Mapping of input bits to 6 selection bits address bit likely oflookup tied to interpretation 0 bi-level dot from contone layer 0 cyan 1bi-level dot from contone layer 1 magenta 2 bi-level dot from contonelayer 2 yellow 3 bi-level dot from contone layer 3 black 4 bi-levelspot0 dot black 5 bi-level tag dot infra-red

Output Buffer

The output buffer de-couples the stalling behaviour of the feeder unitsfrom the stalling behaviour of the DNC. The larger the buffer thegreater de-coupling. Currently the output buffer size is 2, but could beincreased if needed at the cost of extra area.

If the Go bit is set to 0 no read or write of the output buffer ispermitted. On a low to high transition of the Go bit the contents of theoutput buffer are cleared.

The output buffer also implements the interface logic to the DNC. Ifthere is data in the output buffer the hcu_dnc_avail signal will be 1,otherwise is will be 0. If both hcu_dnc_avail and dnc_hcu_ready are 1then data is read from the output buffer.

On the write side if there is space available in the output buffer thelogic indicates to the control unit via the output_buff_full signal. Thecontrol unit will then allow writes to the output buffer via thewr_advdot signal. If the writes to the output buffer are after the endof a page (indicated by in_page equal to 0) then all dots written intothe output buffer are set to zero.

HCU to DNC Interface

FIG. 22 shows the timing diagram and representative logic of the HCU toDNC interface. The hcu_dnc_avail signal indicate to the DNC that the HCUhas data available. The dnc_hcu_ready signal indicates to the HCU thatthe DNC is ready to accept data. When both signals are high data istransferred from the HCU to the DNC. Once the HCU indicates it has dataavailable (setting the hcu_dnc_avail signal high) it can only set thehcu_dnc_avail low again after a dot is accepted by the DNC.

Feeder to HCU Interfaces

FIG. 23 shows the feeder unit to HCU interface timing diagram, and FIG.24 shows representative logic of the interface with the registerpositions. sfu_hcu_data and sfu_hcu_avail are always registered whilethe sfu_hcu_advdot is not. The hcu_sfu_avail signal indicates to the HCUthat the feeder unit has data available, and sfu_hcu_advdot indicates tothe feeder unit that the HCU has captured the last dot. The HCU cannever produce an advance dot pulse while the avail is low. The diagramsshow the example of the SFU to HCU interface, but the same interface isused for the other feeder units TFU and CFU.

Dead Nozzle Compensator (DNC)

The Dead Nozzle Compensator (DNC) is responsible for adjusting Memjetdot data to take account of non-functioning nozzles in the Memjetprinthead. Input dot data is supplied from the HCU, and the correcteddot data is passed out to the DWU. The high level data path is shown bythe block diagram in FIG. 25. The DNC compensates for a dead nozzles byperforming the following operations:

-   -   Dead nozzle removal, i.e. turn the nozzle off    -   Ink replacement by direct substitution i.e. K->K    -   Ink replacement by indirect substitution i.e. K->CMY    -   Error diffusion to adjacent nozzles    -   Fixative corrections

The DNC is required to efficiently support up to 5% dead nozzles, underthe expected DRAM bandwidth allocation, with no restriction on wheredead nozzles are located and handle any fixative correction due tonozzle compensations. Performance must degrade gracefully after 5% deadnozzles.

Dead Nozzle Identification

Dead nozzles are identified by means of a position value and a maskvalue. Position information is represented by a 10-bit delta encodedformat, where the 10-bit value defines the number of dots between deadnozzle columns⁸. With the delta information it also reads the 6-bit deadnozzle mask (dn_mask) for the defined dead nozzle position. Each bit inthe dn_mask corresponds to an ink plane. A set bit indicates that thenozzle for the corresponding ink plane is dead. The dead nozzle tableformat is shown in FIG. 26. The DNC reads dead nozzle information fromDRAM in single 256-bit accesses. A 10-bit delta encoding scheme ischosen so that each table entry is 16 bits wide, and 16 entries fitexactly in each 256-bit read. Using 10-bit delta encoding means that themaximum distance between dead nozzle columns is 1023 dots. It ispossible that dead nozzles may be spaced further than 1023 dots fromeach other, so a null dead nozzle identifier is required. A null deadnozzle identifier is defined as a 6-bit dn_mask of all zeros. These nulldead nozzle identifiers should also be used so that:

-   -   the dead nozzle table is a multiple of 16 entries (so that it is        aligned to the 256-bit DRAM locations)    -   the dead nozzle table spans the complete length of the line,        i.e. the first entry dead nozzle table should have a delta from        the first nozzle column in a line and the last entry in the dead        nozzle table should correspond to the last nozzle column in a        line. ⁸for a 10-bit delta value of d, if the current column n is        a dead nozzle column then the next dead nozzle column is given        by n+(d+1).

Note that the DNC deals with the width of a page. This may or may not bethe same as the width of the printhead (the PHI may introduce somemargining to the page so that its dot output matches the width of theprinthead). Care must be taken when programming the dead nozzle table sothat dead nozzle positions are correctly specified with respect to thepage and printhead.

DRAM Storage and Bandwidth Requirement

The memory required is largely a factor of the number of dead nozzlespresent in the printhead (which in turn is a factor of the printheadsize). The DNC is required to read a 16-bit entry from the dead nozzletable for every dead nozzle. Table 11 shows the DRAM storage andaverage⁹ bandwidth requirements for the DNC for different percentages ofdead nozzles and different page sizes. ⁹Average bandwidth assumes aneven spread of dead nozzles. Clumps of dead nozzles may cause delays dueto insufficient available DRAM bandwidth. These delays will occur everyline causing an accumulative delay over a page.

TABLE 11 Dead Nozzle storage and average bandwidth requirements Deadnozzle table Bandwidth Page size % Dead Nozzles Memory (KBytes)(bits/cycle) A4^(a) 5% 1.4^(c) 0.8^(d) 10% 2.7 1.6 15% 4.1 2.4 A3^(b) 5%1.9 0.8 10% 3.8 1.6 15% 5.7 2.4 ^(a)Bi-lithic printhead has 13824nozzles per color providing full bleed printing for A4/Letter^(b)Bi-lithic printhead has 19488 nozzles per color providing full bleedprinting for A3 ^(c)16 bits × 13824 nozzles × 0.05 dead ^(d)(16 bitsread/20 cycles) = 0.8 bits/cycle

Nozzle Compensation

DNC receives 6 bits of dot information every cycle from the HCU, 1 bitper color plane. When the dot position corresponds to a dead nozzlecolumn, the associated 6-bit dn_mask indicates which ink plane(s)contains a dead nozzle(s). The DNC first deletes dots destined for thedead nozzle. It then replaces those dead dots, either by placing thedata destined for the dead nozzle into an adjacent ink plane (directsubstitution) or into a number of ink planes (indirect substitution).After ink replacement, if a dead nozzle is made active again then theDNC performs error diffusion. Finally, following the dead nozzlecompensation mechanisms the fixative, if present, may need to beadjusted due to new nozzles being activated, or dead nozzles beingremoved.

Dead Nozzle Removal

If a nozzle is defined as dead, then the first action for the DNC is toturn off (zeroing) the dot data destined for that nozzle. This is doneby a bit-wise ANDing of the inverse of the dn_mask with the dot value.

Ink Replacement

Ink replacement is a mechanism where data destined for the dead nozzleis placed into an adjacent ink plane of the same color (directsubstitution, i.e. K->K_(alternative)), or placed into a number of inkplanes, the combination of which produces the desired color (indirectsubstitution, i.e. K->CMY). Ink replacement is performed by filteringout ink belonging to nozzles that are dead and then adding back in anappropriately calculated pattern. This two step process allows theoptional re-inclusion of the ink data into the original dead nozzleposition to be subsequently error diffused. In the general case,fixative data destined for a dead nozzle should not be left activeintending it to be later diffused.

The ink replacement mechanism has 6 ink replacement patterns, one perink plane, programmable by the CPU. The dead nozzle mask is ANDed withthe dot data to see if there are any planes where the dot is active butthe corresponding nozzle is dead. The resultant value forms an enable,on a per ink basis, for the ink replacement process. If replacement isenabled for a particular ink, the values from the correspondingreplacement pattern register are ORed into the dot data. The output ofthe ink replacement process is then filtered so that error diffusion isonly allowed for the planes in which error diffusion is enabled. Theoutput of the ink replacement logic is ORed with the resultant dot afterdead nozzle removal.

For example if we consider the printhead color configurationC,M,Y,K₁,K₂,IR and the input dot data from the HCU is b101100. Assumingthat the K₁ ink plane and IR ink plane for this position are dead so thedead nozzle mask is b000101. The DNC first removes the dead nozzle byzeroing the K₁ plane to produce b101000. Then the dead nozzle mask isANDed with the dot data to give b000100 which selects the inkreplacement pattern for K₁ (in this case the ink replacement pattern forK₁ is configured as b000010, i.e. ink replacement into the K₂ plane).Providing error diffusion for K₂ is enabled, the output from the inkreplacement process is b000010. This is ORed with the output of deadnozzle removal to produce the resultant dot b101010. As can be seen thedot data in the defective K₁ nozzle was removed and replaced by a dot inthe adjacent K₂ nozzle in the same dot position, i.e. directsubstitution.

In the example above the K₁ ink plane could be compensated for byindirect substitution, in which case ink replacement pattern for K₁would be configured as b111000 (substitution into the CMY color planes),and this is ORed with the output of dead nozzle removal to produce theresultant dot b111000. Here the dot data in the defective K₁ ink planewas removed and placed into the CMY ink planes.

Error Diffusion

Based on the programming of the lookup table the dead nozzle may be leftactive after ink replacement. In such cases the DNC can compensate usingerror diffusion. Error diffusion is a mechanism where dead nozzle dotdata is diffused to adjacent dots.

When a dot is active and its destined nozzle is dead, the DNC willattempt to place the data into an adjacent dot position, if one isinactive. If both dots are inactive then the choice is arbitrary, and isdetermined by a pseudo random bit generator. If both neighbor dots arealready active then the bit cannot be compensated by diffusion.

Since the DNC needs to look at neighboring dots to determine where toplace the new bit (if required), the DNC works on a set of 3 dots at atime. For any given set of 3 dots, the first dot received from the HCUis referred to as dot A, and the second as dot B, and the third as dotC. The relationship is shown in FIG. 27.

For any given set of dots ABC, only B can be compensated for by errordiffusion if B is defined as dead. A 1 in dot B will be diffused intoeither dot A or dot C if possible. If there is already a 1 in dot A ordot C then a 1 in dot B cannot be diffused into that dot.

The DNC must support adjacent dead nozzles. Thus if dot A is defined asdead and has previously been compensated for by error diffusion, thenthe dot data from dot B should not be diffused into dot A. Similarly, ifdot C is defined as dead, then dot data from dot B should not bediffused into dot C.

Error diffusion should not cross line boundaries. If dot B contains adead nozzle and is the first dot in a line then dot A represents thelast dot from the previous line. In this case an active bit on a deadnozzle of dot B should not be diffused into dot A. Similarly, if dot Bcontains a dead nozzle and is the last dot in a line then dot Crepresents the first dot of the next line. In this case an active bit ona dead nozzle of dot B should not be diffused into dot C. Thus, as arule, a 1 in dot B cannot be diffused into dot A if

-   -   a 1 is already present in dot A,    -   dot A is defined as dead,    -   or dot A is the last dot in a line.        Similarly, a 1 in dot B cannot be diffused into dot C if    -   a 1 is already present in dot C,    -   dot C is defined as dead,    -   or dot C is the first dot in a line.        If B is defined to be dead and the dot value for B is 0, then no        compensation needs to be done and dots A and C do not need to be        changed. If B is defined to be dead and the dot value for B is        1, then B is changed to 0 and the DNC attempts to place the 1        from B into either A or C:    -   If the dot can be placed into both A and C, then the DNC must        choose between them. The preference is given by the current        output from the random bit generator, 0 for “prefer left”        (dot A) or 1 for “prefer right” (dot C).    -   If dot can be placed into only one of A and C, then the 1 from B        is placed into that position.    -   If dot cannot be placed into either one of A or C, then the DNC        cannot place the dot in either position. Table 12 shows the        truth table for DNC error diffusion operation when dot B is        defined as dead.

TABLE 12 Error Diffusion Truth Table when dot B is dead Input C A OR ORC dead A dead OR OR C first in Output A last in line B line Rand{graveover ( )}a A B C 0 0 0 X A input 0 C input 0 0 1 X A input 0 C input 0 10 0 1{grave over ( )}b 0 C input 0 1 0 1 A input 0 1 0 1 1 X 1 0 C input1 0 0 X A input 0 C input 1 0 1 X A input 0 C input 1 1 0 X A input 0 11 1 1 X A input 0 C input a. Output from random bit generator.Determines direction of error diffusion (0 = left, 1 = right) b. Boldemphasis is used to show the DNC inserted a 1

The random bit value used to arbitrarily select the direction ofdiffusion is generated by a 32-bit maximum length random bit generator.The generator generates a new bit for each dot in a line regardless ofwhether the dot is dead or not. The random bit generator can beinitialized with a 32-bit programmable seed value.

Fixative Correction

After the dead nozzle compensation methods have been applied to the dotdata, the fixative, if present, may need to be adjusted due to newnozzles being activated, or dead nozzles being removed. For each outputdot the DNC determines if fixative is required (using theFixativeRequiredMask register) for the new compensated dot data word andwhether fixative is activated already for that dot. For the DNC to do soit needs to know the color plane that has fixative, this is specified bythe FixativeMask1 configuration register. See Table 15 below whichindicates the actions to take based on these calculations.

The DNC also allows the specification of another fixative plane,specified by the FixativeMask2 configuration register, withFixativeMask1 having the higher priority over FixativeMask2. Whenattempting to add fixative the DNC first tries to add it into the planesdefined by FixativeMask1. However, if any of these planes is dead thenit tries to add fixative by placing it into the planes defined byFixativeMask2.

Note that the fixative defined by FixativeMask1 and FixativeMask2 couldpossibly be multi-part fixative, i.e. 2 bits could be set inFixativeMask1 with the fixative being a combination of both inks.

Implementation

A block diagram of the DNC is shown in FIG. 28.

TABLE 13 DNC port list and description Port name Pins I/O DescriptionClocks and Resets Pclk 1 In System Clock. prst_n 1 In System reset,synchronous active low. PCU interface pcu_dnc_sel 1 In Block select fromthe PCU. When pcu_dnc_sel is high both pcu_adr and pcu_dataout arevalid. pcu_rwn 1 In Common read/not-write signal from the PCU.pcu_adr[6:2] 5 In PCU address bus. Only 5 bits are required to decodethe address space for this block. pcu_dataout[31:0] 32 In Shared writedata bus from the PCU. dnc_pcu_rdy 1 Out Ready signal to the PCU. Whendnc_pcu_rdy is high it indicates the last cycle of the access. For awrite cycle this means pcu_dataout has been registered by the block andfor a read cycle this means the data on dnc_pcu_datain is valid.dnc_pcu_datain[31:0] 32 Out Read data bus to the PCU. DIU interfacednc_diu_rreq 1 Out DNC unit requests DRAM read. A read request must beaccompanied by a valid read address. dnc_diu_radr[21:5] 17 Out Readaddress to DIU, 256-bit word aligned. diu_dnc_rack 1 In Acknowledge fromDIU that read request has been accepted and new read address can beplaced on dnc_diu_radr diu_dnc_rvalid 1 In Read data valid, active high.Indicates that valid read data is now on the read data bus, diu_data.diu_data[63:0] 64 In Read data from DIU. HCU interface dnc_hcu_ready 1Out Indicates that DNC is ready to accept data from the HCU.hcu_dnc_avail 1 In Indicates valid data present on hcu_dnc_data.hcu_dnc_data[5:0] 6 In Output bi-level dot data in 6 ink planes. DWUinterface dwu_dnc_ready 1 In Indicates that DWU is ready to accept datafrom the DNC. dnc_dwu_avail 1 Out Indicates valid data present ondnc_dwu_data. dnc_dwu_data[5:0] 6 Out Output bi-level dot data in 6 inkplanes.

Configuration Registers

The configuration registers in the DNC are programmed via the PCUinterface. Note that since addresses in SoPEC are byte aligned and thePCU only supports 32-bit register reads and writes, the lower 2 bits ofthe PCU address bus are not required to decode the address space for theDNC. When reading a register that is less than 32 bits wide zeros shouldbe returned on the upper unused bit(s) of dnc_pcu_datain. Table 14 liststhe configuration registers in the DNC.

TABLE 14 DNC configuration registers Address Register Value (DNC_base+)name #bits on reset Description Control registers 0x00 Reset 1 0x1 Awrite to this register causes a reset of the DNC. 0x04 Go 1 0x0 Writing1 to this register starts the DNC. Writing 0 to this register halts theDNC. When Go is asserted all counters, flags etc. are cleared or giventheir initial value, but configuration registers keep their values. WhenGo is deasserted the state-machines go to their idle states but allcounters and configuration registers keep their values. This registercan be read to determine if the DNC is running (1 = running, 0 =stopped). Setup registers (constant during processing) 0x10 MaxDot 160x0000 This is the maximum dot number −1 present across a page. Forexample if a page contains 13824 dots, then MaxDot will be 13823. Notethat this number may or may not be the same as the number of dots acrossthe printhead as some margining may be introduced in the PHI. 0x14 LSFR32 0x0000_0000 The current value of the LFSR register used as the 32-bitmaximum length random bit generator. Users can write to this register toprogram a seed value for the 32- bit maximum length random bitgenerator. Must not be all 1s for taps implemented in XNOR form. (It isexpected that writing a seed value will not occur during the operationof the LFSR). This LSFR value could also have a possible use as a randomsource in program code. 0x20 FixativeMask1 6 0x00 Defines the higherpriority fixative plane(s). Bit 0 represents the settings for plane 0,bit 1 for plane 1 etc. For each bit: 1 = the ink plane containsfixative. 0 = the ink plane does not contain fixative. 0x24FixativeMask2 6 0x00 Defines the lower priority fixative plane(s). Bit 0represents the settings for plane 0, bit 1 for plane 1 etc. Used onlywhen FixativeMask1 planes are dead. For each bit: 1 = the ink planecontains fixative. 0 = the ink plane does not contain fixative. 0x28FixativeRequiredMask 6 0x00 Identifies the ink planes that requirefixative. Bit 0 represents the settings for plane 0, bit 1 for plane 1etc. For each bit: 1 = the ink plane requires fixative; 0 = the inkplane does not require fixative (e.g. ink is self-fixing) 0x30DnTableStartAdr[21:5] 17 0x0_0000 Start address of Dead Nozzle Table inDRAM, specified in 256-bit words. 0x34 DnTableEndAdr[21:5] 17 0x0_0000End address of Dead Nozzle Table in DRAM, specified in 256-bit words,i.e. the location containing the last entry in the Dead Nozzle Table.The Dead Nozzle Table should be aligned to a 256-bit boundary, ifnecessary it can be padded with null entries. 0x40-0x54PlaneReplacePattern[5:0] 6 × 6 0x00 Defines the ink replacement patternfor each of the 6 ink planes. PlaneReplacePattern[0] is the inkreplacement pattern for plane 0, PlaneRelace Pattern[1] is the inkreplacement pattern for plane 1, etc. For each 6-bit replacement patternfor a plane, a 1 in any bit positions indicates the alternative inkplanes to be used for this plane. 0x58 DiffuseEnable 6 0x3F Defineswhether, after ink replacement, error diffusion is allowed to beperformed on each plane. Bit 0 represents the settings for plane 0, bit1 for plane 1 etc. For each bit: 1 = error diffusion is enabled; 0 =error diffusion is disabled Debug registers (read only) 0x60DncOutputDebug 8 N/A Bit 7 = dwu_dnc_ready Bit 6 = dnc_dwu_avail Bits5-0 = dnc_dwu_data 0x64 DncReplaceDebug 14 N/A Bit 13 = edu_ready Bit 12= iru_avail Bits 11-6 = iru_dn_mask Bits 5-0 = iru_data 0x68DncDiffuseDebug 14 N/A Bit 13 = dwu_dnc_ready Bit 12 = dnc_dwu_availBits 11-6 = edu_dn_mask Bits 5-0 = edu_data

Ink Replacement Unit

FIG. 29 shows a sub-block diagram for the ink replacement unit.

Control Unit

The control unit is responsible for reading the dead nozzle table fromDRAM and making it available to the DNC via the dead nozzle FIFO. Thedead nozzle table is read from DRAM in single 256-bit accesses,receiving the data from the DIU over 4 clock cycles (64-bits per cycle).Reading from DRAM is implemented by means of the state machine shown inFIG. 30.

All counters and flags should be cleared after reset. When Gotransitions from 0 to 1 all counters and flags should take their initialvalue. While the Go bit is 1, the state machine requests a read accessfrom the dead nozzle table in DRAM provided there is enough space in itsFIFO.

A modulo-4 counter, rd_count, is used to count each of the 64-bitsreceived in a 256-bit read access. It is incremented wheneverdiu_dnc_rvalid is asserted. When Go is 1, dn_table_radr is set todn_table_start_adr. As each 64-bit value is returned, indicated bydiu_dnc_rvalid being asserted, dn_table_radr is compared todn_table_end_adr:

-   -   If rd_count equals 3 and dn_table_radr equals dn_table_end_adr,        then dn_table_radr is updated to dn_table_start_adr.    -   If rd_count equals 3 and dn_table_radr does not equal        dn_table_end_adr, then dn_table_radr is incremented by 1.

A count is kept of the number of 64-bit values in the FIFO. Whendiu_dnc_rvalid is 1 data is written to the FIFO by asserting wr_en, andfifo_contents and fifo_wr_adr are both incremented.

When fifo_contents[3:0] is greater than 0 and edu_ready is 1,dnc_hcu_ready is asserted to indicate that the DNC is ready to acceptdots from the HCU. If hcu_dnc_avail is also 1 then a dotadv pulse issent to the GenMask unit, indicating the DNC has accepted a dot from theHCU, and iru_avail is also asserted. After Go is set, a single preloadpulse is sent to the GenMask unit once the FIFO contains data.

When a rd_adv pulse is received from the GenMask unit, fifo_rd_adr[4:0]is then incremented to select the next 16-bit value. Iffifo_rd_adr[1:0]=11 then the next 64-bit value is read from the FIFO byasserting rd_en, and fifo_contents[3:0] is decremented.

Dead Nozzle FIFO

The dead nozzle FIFO conceptually is a 64-bit input, and 16-bit outputFIFO to account for the 64-bit data transfers from the DIU, and theindividual 16-bit entries in the dead nozzle table that are used in theGenMask unit. In reality, the FIFO is actually 8 entries deep and64-bits wide (to accommodate two 256-bit accesses).

On the DRAM side of the FIFO the write address is 64-bit aligned whileon the GenMask side the read address is 16-bit aligned, i.e. the upper 3bits are input as the read address for the FIFO and the lower 2 bits areused to select 16 bits from the 64 bits (1st 16 bits read corresponds tobits 15-0, second 16 bits to bits 31-16 etc.).

GenMask Unit

The GenMask unit generates the 6-bit dn_mask that is sent to the replaceunit. It consists of a 10-bit delta counter and a mask register.

After Go is set, the GenMask unit will receive a preload pulse from thecontrol unit indicating the first dead nozzle table entry is availableat the output of the dead nozzle FIFO and should be loaded into thedelta counter and mask register. A rd_adv pulse is generated so that thenext dead nozzle table entry is presented at the output of the deadnozzle FIFO. The delta counter is decremented every time a dotadv pulseis received. When the delta counter reaches 0, it gets loaded with thecurrent delta value output from the dead nozzle FIFO, i.e. bits 15-6,and the mask register gets loaded with mask output from the dead nozzleFIFO, i.e. bits 5-0. A rd_adv pulse is then generated so that the nextdead nozzle table entry is presented at the output of the dead nozzleFIFO.

When the delta counter is 0 the value in the mask register is output asthe dn_mask, otherwise the dn_mask is all 0s. The GenMask unit has noknowledge of the number of dots in a line, it simply loads a counter tocount the delta from one dead nozzle column to the next. Thus the deadnozzle table should include null identifiers if necessary so that thedead nozzle table covers the first and last nozzle column in a line.

Replace Unit

Dead nozzle removal and ink replacement are implemented by thecombinatorial logic shown in FIG. 31. Dead nozzle removal is performedby bit-wise ANDing of the inverse of the dn_mask with the dot value.

The ink replacement mechanism has 6 ink replacement patterns, one perink plane, programmable by the CPU. The dead nozzle mask is ANDed withthe dot data to see if there are any planes where the dot is active butthe corresponding nozzle is dead. The resultant value forms an enable,on a per ink basis, for the ink replacement process. If replacement isenabled for a particular ink, the values from the correspondingreplacement pattern register are ORed into the dot data. The output ofthe ink replacement process is then filtered so that error diffusion isonly allowed for the planes in which error diffusion is enabled.

The output of the ink replacement process is ORed with the resultant dotafter dead nozzle removal. If the dot position does not contain a deadnozzle then the dn_mask will be all 0s and the dot, hcu_dnc_data, willbe passed through unchanged.

Error Diffusion Unit

FIG. 32 shows a sub-block diagram for the error diffusion unit.

Random Bit Generator

The random bit value used to arbitrarily select the direction ofdiffusion is generated by a maximum length 32-bit LFSR. The tap pointsand feedback generation are shown in FIG. 33. The LFSR generates a newbit for each dot in a line regardless of whether the dot is dead or not,i.e shifting of the LFSR is enabled when advdot equals 1. The LFSR canbe initialised with a 32-bit programmable seed value, random_seed. Thisseed value is loaded into the LFSR whenever a write occurs to theRandomSeed register. Note that the seed value must not be all 1s as thiscauses the LFSR to lock-up.

Advance Dot Unit

The advance dot unit is responsible for determining in a given cyclewhether or not the error diffuse unit will accept a dot from the inkreplacement unit or make a dot available to the fixative correct unitand on to the DWU. It therefore receives the dwu_dnc_ready controlsignal from the DWU, the iru_avail flag from the ink replacement unit,and generates dnc_dwu_avail and edu_ready control flags.

Only the dwu_dnc_ready signal needs to be checked to see if a dot can beaccepted and asserts edu_ready to indicate this. If the error diffuseunit is ready to accept a dot and the ink replacement unit has a dotavailable, then a advdot pulse is given to shift the dot into thepipeline in the diffuse unit. Note that since the error diffusionoperates on 3 dots, the advance dot unit ignores dwu_dnc_ready initiallyuntil 3 dots have been accepted by the diffuse unit. Similarlydnc_dwu_avail is not asserted until the diffuse unit contains 3 dots andthe ink replacement unit has a dot available.

Diffuse Unit

The diffuse unit contains the combinatorial logic to implement the truthtable. The diffuse unit receives a dot consisting of 6 color planes (1bit per plane) as well as an associated 6-bit dead nozzle mask value.

Error diffusion is applied to all 6 planes of the dot in parallel. Sinceerror diffusion operates on 3 dots, the diffuse unit has a pipeline of 3dots and their corresponding dead nozzle mask values. The first dotreceived is referred to as dot A, and the second as dot B, and the thirdas dot C. Dots are shifted along the pipeline whenever advdot is 1. Acount is also kept of the number of dots received. It is incrementedwhenever advdot is 1, and wraps to 0 when it reaches max_dot. When thedot count is 0 dot C corresponds to the first dot in a line. When thedot count is 1 dot A corresponds to the last dot in a line.

In any given set of 3 dots only dot B can be defined as containing adead nozzle(s). Dead nozzles are identified by bits set in iru_dn_mask.If dot B contains a dead nozzle(s), the corresponding bit(s) in dot A,dot C, the dead nozzle mask value for A, the dead nozzle mask value forC, the dot count, as well as the random bit value are input to the truthtable logic and the dots A, B and C assigned accordingly. If dot B doesnot contain a dead nozzle then the dots are shifted along the pipelineunchanged.

Fixative Correction Unit

The fixative correction unit consists of combinatorial logic toimplement fixative correction as defined in Table 15. For each outputdot the DNC determines if fixative is required for the new compensateddot data word and whether fixative is activated already for that dot.

-   -   FixativePresent=((FixativeMask1|FixativeMask2) & edu_data) !=0    -   FixativeRequired=(FixativeRequiredMask & edu_data) !=0        It then looks up the truth table to see what action, if any,        needs to be taken.

TABLE 15 Truth table for fixative correction Fixative Fixative Presentrequired Action Output 1 1 Output dot as is. dnc_dwu_data = edu_data 1 0Clear fixative dnc_dwu_data = (edu_data) & plane. ~(FixativeMask1 |FixativeMask2) 0 1 Attempt to if (FixativeMask1 & DnMask) != 0 addfixative. dnc_dwu_data = (edu_data) | (FixativeMask2 & ~DnMask) elsednc_dwu_data = (edu_data) | (FixativeMask1) 0 0 Output dot as is.dnc_dwu_data = edu_data

When attempting to add fixative the DNC first tries to add it into theplane defined by FixativeMask1. However, if this plane is dead then ittries to add fixative by placing it into the plane defined byFixativeMask2. Note that if both FixativeMask1 and FixativeMask2 areboth all 0s then the dot data will not be changed.

Dotline Writer Unit (DWU)

The Dotline Writer Unit (DWU) receives 1 dot (6 bits) of colorinformation per cycle from the DNC. Dot data received is bundled into256-bit words and transferred to the DRAM. The DWU (in conjunction withthe LLU) implements a dot line FIFO mechanism to compensate for thephysical placement of nozzles in a printhead, and provides data ratesmoothing to allow for local complexities in the dot data generatepipeline.

The physical placement of nozzles in the printhead means that in onefiring sequence of all nozzles, dots will be produced over several printlines. The printhead consists of 12 rows of nozzles, one for each colorof odd and even dots. Odd and even nozzles are separated by D₂ printlines and nozzles of different colors are separated by D₁ print lines.See FIG. 35 for reference. The first color to be printed is the firstrow of nozzles encountered by the incoming paper. In the example this iscolor 0 odd, although is dependent on the printhead type. Paper passesunder printhead moving downwards.

For example if the physical separation of each half row is 80 □mequating to D₁=D₂=5 print lines at 1600 dpi. This means that in onefiring sequence, color 0 odd nozzles will fire on dotline L, color 0even nozzles will fire on dotline L-D₁, color 1 odd nozzles will fire ondotline L-D₁-D₂ and so on over 6 color planes odd and even nozzles. Thetotal number of lines fired over is given as 0+5+5 . . . +5=0+11×5=55.See FIG. 36 for example diagram.

It is expected that the physical spacing of the printhead nozzles willbe 80 μm (or 5 dot lines), although there is no dependency on nozzlespacing. The DWU is configurable to allow other line nozzle spacings.

Line Loader Unit (LLU)

The Line Loader Unit (LLU) reads dot data from the line buffers in DRAMand structures the data into even and odd dot channels destined for thesame print time. The blocks of dot data are transferred to the PHI andthen to the printhead. FIG. 48 shows a high level data flow diagram ofthe LLU in context.

The DWU re-orders dot data into 12 separate dot data line FIFOs in theDRAM. Each FIFO corresponds to 6 colors of odd and even data. The LLUreads the dot data line FIFOs and sends the data to the printheadinterface. The LLU decides when data should be read from the dot dataline FIFOs to correspond with the time that the particular nozzle on theprinthead is passing the current line. The interaction of the DWU andLLU with the dot line FIFOs compensates for the physical spread ofnozzles firing over several lines at once. FIG. 49 shows the physicalrelationship of nozzle rows and the line time the LLU starts readingfrom the dot line store.

Within each line of dot data the LLU is required to generate an even andodd dot data stream to the PHI block. FIG. 50 shows the even and dotstreams as they would map to an example bi-lithic printhead. The PHIblock determines which stream should be directed to which printhead IC.

PrintHead Interface (PHI)

The Printhead interface (PHI) accepts dot data from the LLU andtransmits the dot data to the printhead, using the printhead interfacemechanism. The PHI generates the control and timing signals necessary toload and drive the bi-lithic printhead. The CPU determines the lineupdate rate to the printhead and adjusts the line sync frequency toproduce the maximum print speed to account for the printhead IC's sizeratio and inherent latencies in the syncing system across multipleSoPECs. The PHI also needs to consider the order in which dot data isloaded in the printhead. This is dependent on the construction of theprinthead and the relative sizes of printhead ICs used to create theprinthead.

The printing process is a real-time process. Once the printing processhas started, the next printline's data must be transferred to theprinthead before the next line sync pulse is received by the printhead.Otherwise the printing process will terminate with a buffer underrunerror. The PHI can be configured to drive a single printhead IC with orwithout synchronization to other SoPECs. For example the PHI could drivea single IC printhead (i.e. a printhead constructed with one IC only),or dual IC printhead with one SoPEC device driving each printhead IC.

The PHI interface provides a mechanism for the CPU to directly controlthe PHI interface pins, allowing the CPU to access the bi-lithicprinthead to:

-   -   determine printhead temperature    -   test for and determine dead nozzles for each printhead IC    -   initialize each printhead IC    -   pre-heat each printhead IC        FIG. 58 shows a high level data flow diagram of the PHI in        context.

1. A printer controller for compensating for an inoperative nozzle in aprinthead, the printhead including a plurality of nozzles associatedwith each pixel to be printed, the printer controller being operative tocontrol one or more operative nozzles associated with the same pixel asthe inoperative nozzle to increase the amount of printing substanceexpelled by the one or more operative nozzles.
 2. A printer controlleras claimed in claim 1, wherein the printer controller compensates forthe inoperative nozzle by increasing the amount of printing substanceexpelled by one or more operative nozzles expelling printing substancewith a color substantially similar to the color expelled by theinoperative nozzle.
 3. A printer controller as claimed in claim 1,wherein there are six nozzles associated with each pixel and the amountof printing substance expelled by each nozzle is bi-level.
 4. A printercontroller as claimed in claim 1, wherein information indicatinginoperative nozzles is stored in a table.
 5. A printer controller asclaimed in claim 4, wherein the table is updated by performing aninoperative nozzle test including the steps of: running a printheadnozzle test sequence; converting inoperative nozzle information into aninoperative nozzle table; and, writing the inoperative nozzle table to amemory of the printer controller.
 6. A printer controller as claimed inclaim 1, wherein the inoperative nozzle is associated with a black printchannel, and wherein dot data intended for the inoperative nozzle ismapped into a plurality of operative nozzles associated with the samepixel as the inoperative nozzle in other color channels to produce aprocess black output substantially at a location on print media wherethe inoperative nozzle would have deposited a dot of a black printingsubstance in accordance with the dot data.
 7. A printer controller asclaimed in claim 1, wherein the increased amounts of printing substanceexpelled by the one or more operative nozzles forms a pixel with a colorsubstantially similar to the color expelled by the inoperative nozzle.